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mechanism(s) guarding the content, and finally an unauthorized modification of that protection in 
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(57) Abstract: Theft, distribution, and 
piracy of digital content (software, \'ideo, 
audio, e-hnoks, any content of any kind 
that is digitally stored and distributed) 
is generally accomplished by copying 
it, if possible, or, if it is protected from 
being copied in any fashion, such piracy 
is based upon a number of reverse 
engineering techniques. Aside from the 
straightforward copying of unprotected 
content, all of these other methods require 
first an understanding of the protective 
mechanism(s) guarding the content, and 
finally an unauthorized modification 
of that protection in order to disable or 
subvert it. Methods that prevent a skilled 
indi%idual from using teverse engineering 
tools and tecliniques to attain that level of 
understanding and/or prevent anyone from 
performing such modifications can offer 
significant advantages to content creators 
who wish to protect their products. 
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SYSTEMS AND TVrETHOPS FOR PREVENTING 
TTNATTTHQRIZFT^ TTSE OF DIG TTAT. CONTENT 

PffT ATFT) APPLICATIONS 

This application is a continuation-in-part application of United States Patent 

Application Number 09/960,610, filed September 21, 2001, which application claims 

the benefit of United States Provisional Application Serial No. 60/234,657, filed 

September 22, 2000, United States Provisional Application Serial No. 60/240,61 1, 

filed October 16, 2000, United States Provisional Application Serial No. 60/242,949, 

filed October 24, 2000, and United States Provisional AppUcation Serial No. 

60/244,704, filed October 31, 2000. 

This application also claims the benefit of United States Provisional 

Application Serial No. 60/249,946, filed November 20, 2000, United States 
Provisional Application Serial No. 60/260,705, filed January 10, 2001, and United 
States Provisional Application Serial No. 60/285,300, filed April 20, 2001 . 

The contents of the applications referenced above are incorporated herein by 
reference, in their entirety. 

RACKGROUNl) OF THE INVENTION 

FiRld nf the Invention 

This invention is related to the field of protecting digital information firom 
being copied, modified, or used by unauthorized parties. In particular this invention 
is related to systems and methods that prevent unauthorized access to, and 
modification of, digital data as found on computer systems and consumer-appliance 
systems that utilize Compact Disc (CD), DVD, or other removable media (such as 
Flash Memory on standard or proprietary cards or sticks, or other non-volatile 
memory) technologies, or any storage media of any type, or any such content 
delivared via any network connection of any type. 
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Description of the Related Art 

The electronic publishing industry for application software, computer games, 

appliance-console games, movies, and music, is facing a growing and serious 

problem; namely, the piracy and unauthorized modification and use of their content 

Since digital content is by nature capable of beiiig copied exactly, wherein a copy is 

identical in every way to the original, and since the tools to do so are increasingly 

available, the industry is facing increasing losses. Such losses may include the 

unauthorized copying of a CD containing a game, or the unauthorized reverse 

engineering and modification of a word processing program to allow for its illegal 

distribution, or the reverse engineering of a copy protection scheme to disable it, 

» 

making it possible to make duplicates with ease. 

There are many mechanisms available that may be used to limit or prevent 
unauthorized access to digital content Following deployment, such mechanisms are 
often times subsequently compromised by hackers, and the methods and techniques 
used to compromise them have been widely disseminated and actively used and 
enhanced. Most protections are simplistic in nature, and depend to large degree on 
the secrecy of the simple method as much as its inherent security or ingenuity, such 
that if not defeated prior to publication, the act of publishing them, for example in 
patent form, reveals enough about them to render them less effective. More than one 
of these approaches may be defeated if anticipated by using "ProcDump", a memory 
lifting tool that is available free on the Worid Wide Web (such a tool may also be 
easily vmtten following technical instructions that may also be found on the web) in 
conjunction with SoftlCE, a powerful debugging tool, which may also be found on 
the web. A computer system is usually the platform and tool of choice for one intent 
on reverse engineering or cracking these protection mechanisms; even if the 
protected content's target was not a computer system such as a PC but rather an 
appliance computing device such as a game console, the content can best be 
modified C^iacked") on a computer. In terms of protecting content from copying or 
modification by a skilled person with a modem computer system, most inventions in 
the field (see below) are not protected fix)m being reverse engineered, modified, or 
contbnt-duplicated by means of commonly available tools such as "SoftlCE" (an in- 
circuit emulator and very powerfiil debugger), 'TrocDump" (can capture any data 
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content from any memory location, regardless of how protected the memory was 
thought to be), "IDA" (a disassembler), and "FileMon" (a file system monitoring and 
transcribing service tool). There are no design secrets that can be kept from such a 
set of tools, and there are many more such tools in existence, and more being created 
all the tune. Therefore it becomes far more important to have well designed 
mechanisms that do not depend on their secrecy, as much as their design, to ensure 
security. 

Many of these mechanisms depend to a great extent on lack of knowledge 
about the mechanisms by the persons attempting to modify or copy the content. With 
even partial knowledge, many of these mechanisms can be defeated by even a 
moderately technical person with access to the web where all the necessary tools and 
techniques are available. There is a need for security methods that do not depend 
solely upon their secrecy or obscurity in order to be effective. 

Summary of the Invention 

To address the limitations of the conventional approaches described above, 
the present invention is directed to a digital content security method and system that 
does not depend solely upon secrecy or obscurity in order to be effective. 

In one aspect, the present invention is directed to a system and method for 
storing encrypted data, subdivided into arbitrarily small collections of bits within 
other files, or between them, or outside a file system's known storage areas entirely. 
The data size used in the discussion below is 4-bit nibbles and 8-bit bytes , but it 
should be noted that any data size is applicable to the principles of the present 
invention. The location for tlae information is arrived at algorithmically, and no 
single individual location is inherently secret, but knowledge of the totality of the 
locations and their order of traversal is critical. The content is encrypted, but before 
being encrypted, each 8-bit word or byte is broken down into 4-bit nibbles, and is 
merged 4 bits at a time with a completely unrelated stream of bits, which may also 
themselves be equally meaningful 4-bit nibbles. Such interieaved multiplexing is not 
limited to the two-way example above, but may be considered N-way, where N is an 
arbitrary positive integer of any size. 
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In another aspect of the present invention, the locations are not dynamically 
arrived at but are rather chosen by a mapping process and an encoded location map 
is generated. This map maybe itself encrypted, then subdivided into 4-bit nibbles or 
8-bit bytes and itself hidden. 

In another aspect of the present invention, any encrypted file is locked by 
taking its decryption key and then encrypting that key using another encryption 
method or key. The encrypted key is placed in a known location, such as the 
beginning, end, or at a known offset within the file, or is subdivided into bits and 
scattered into the file in known, and therefore retrievable, locations. The locked file 
itself may then be subdivided, multiplexed, further encrypted, and hidden, as needed. 

In another aspect of the present invention, content can be replaced with 
translocated content, such that, in the example of executable content, the file a.exe is 
replaced with another file a.exe. The contents of a.exe are encrypted, locked, and 
hidden as described above. Upon execution of a.exe the content is retrieved, 
dea^pted if necessary, executed as desired. This is not to imply a limitation to 
executable software content such as .exe files; all other digital content, such as an 
audio a.wav file, can have one or more associations in preference order, with 
execution environments such as a variety of MPS or audio software players. The 
playback environment can be provided within the secured entity, or can be 
something that was always resident on the system prior to installation of the secured 
entity. 

In another aspect of the present invention, digital content (whether or not it is 
also hidden and/or encrypted) is modified such that it is tokenized or otherwise 
obfuscated, and then when it comes time for the content to be used, it is interpreted 
within a custom interpreter that is a part of the system. An example of such is to 
modify a compiler such that the assembly language output is nonstandard, and thus 
require that the execution occur in an interpreter designed for the task. Such 
construction is possible even using decades-old utilities such as LEXX and YaCC, 
traditionally compila: creation tools. Such an interpreter is composed of a parser 
which consumes tokens, converts the tokenized logic to native computing 
instructions, obfuscates these instructions with anti-disassembly logic, and feeds 
them to the standard system interfaces. Such interposition of execution layers makes 
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debugging a nontrivial task, and the anti-disassembly logic eliminates the use of 
many popular disassembly tools 

In another aspect, the present invention employs saturation "chaff' logic to 
create a large amount of harmless and meaningless (yet utterly real in appearance 
and content, and apparently meaningful) information desigued to saturate or confuse 
logging, reverse engineering, and debugging tools. Such logic can be targeted at 
specific systems, such that large amounts of I/O to the CD device can be used to 
mask any meaningful activity that may also be occurring on a device. The saturation 
invention is particularly useful against attempts to reverse engineer a protection 
system by monitoring its activity, because any such eventual logging/journal output 
ofthese tools must be reviewed and interpreted by human beings, and the overall 
volume (instead of 100 or 500 lines of logging on a device in a few minutes, this 
invention can generate tens of thousands of spurious log events in the same time 
period) can make it difficult or impossible to sort out the useful information from the 
chaff. 

In another aspect, the present invention prevents sophisticated monitoring 
tools from monitoring and logging file access. Tids is accompUshed by creating a 
driver extension layer, referred to as a "shim", and attaching it to all appropriate 
operating system interfaces. Note that these shim interfaces on most consumer 
computer operating systems allow chaming, so that multiple layers can be stacked 
dynamically. This is also commonly caUed "hooking" on Windows operating 
systems. The present invention provides security by selecting wh«a:e to hook 
(whether you choose to hook before or after a monitoring shim/hooking tool, such as 
FileMon, is significant; one can even hook both before AND after, to provide the 
tool with spurious input information). The mechanism rehooks at the desired 
depth(s) with variable frequency to defeat subsequent monitoring tool invocations. 

In another aspect the present invention creates a driver extension layer, and 
shims or hooks the all relevant operating system interfaces, (and re-attach as above if 
desired). In this aspect, access filtering capabilities are employed to alter access to 
secured content, or to security-threat content 
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In another aspect, the present invention employs an authorization process, 
which serves as a significant part of the decision in determining the status and 
origins of a task or process on the system and make an access determination. 

In another aspect, the present invention includes an "assassin" construct; a 
system entity that operates to monitor activity and take action as needed. If, for 
example, the system were composed of multiple processes, one or more of which 
were protective by nature, and someone were to kill or stop one of the protective 
processes, an assassin process would take note of that occurrence, and would take 
action. The authorization process described below is a significant part of this 
decision in determining the status and origins of a task or process on the system. 
Such action might include disabling the rest of the system to prevent tampering, or 
kilHng the tampering process, or both. Assassui constructs are most useful if they 
serve some other purpose essential to the system, such as if, in the example above, 
the assassin process also served as a system's decryption service, such that killing 
the assassin would result in loss of ability to decrypt by the system, guaranteeing 
failure. Such assassin processes can detect the existence of specific tools both 
dormant and active, and prohibit the protective system's exposure to them. 

In another aspect, the present invention includes an "authorization" construct. 
Such a process is aware of how the operating system tracks the lineage of processes 
and tasks, and can determme parentage quickly and accurately, so that is can be used 
to authorize file accesses to appropriate subtasks of an authorized task. On many 
operating systems the level of identification required by the system is insufficient so 
this aspect of the invention can bypass system query utilities and instead walk tiie 
system's process memory and track tiie lineage, creation, and deletion of processes 
and tasks. 

In view of the above, the present invention is first directed to a system and 
method for preventing unauthorized use of digital content data. Digital content data 
is subdivided into data segments. The data segments are modified with second data 
to generate modified data. The modified data are then stored at predetermined 
memory locations. 
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It is noted that the digital content data may comprise any form of digital data 
that is stored, transmitted, or utilized on or between computer systems of all types. 
Such data includes, but is not limited to, audio, video, documents, electronic text and 
software and the like. 

The data segments are preferably of a variable length, and the second data 
preferably comprises a randomly generated data stream. The second data may 
optionally comprise portions of the digital content data. 

The modified data may likewise be encrypted and stored, for example with 
an encryption key, which, may in turn itself be encrypted. The encryption key may 
be stored with the encrypted modified data at the predetermined memory locations, 
and may be partitioned among the encrypted modified data. 

The digital contMit data may comprise first and second digital content data, 
wherein the predetoraiined memory locations are selected as combinations of the 
locations at which the first and second digital content data were originally stored. A 
map of locations at which the modified data is stored maybe generated and stored at 
the predetermined memory locations. 

In a preferred embodiment, the memory locations reside on a system and the 
system is scanned to determine available memory locations. Target memory 
locations within the available memory locations at which to store the modified data 
are determined. The modified data is tiien stored at the target memory locations. 
The available memory locations maybe located within file system locations and 
outside file system locations. 

Modification of the data segments preferably conq)rises interleaving tiie data 
segments with the second data to generate interieaved data. The second data maybe 
tokenized, for example with lexical equivalents of assembly language commands. 
The lexical equivalents maybe consumed by a system interpreter, in turn generating 
alternative assembly language commands selected to obfiascate the digital content 
data in the event of an unauthorized access. 

The present invention is also directed to a method and system for preventing 
unauthorized use of digital content data in a system havmg memory locations 
comprising. Digital content data is subdivided into data segments, which are, in 
turn, modified with second data to generate modified data. The system is scanned to 
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determine available memory locations and target memory locations within the 
available memory locations at which to store the modified data are sdected. The 
modified data are then stored at the target memory locations. 

The present invention is fijrther directed to a method and system for 
preventing xanauthorized use of digital content data hosted on a system. Digital 
content data is modified with saturation data to generate modified data, and the 
modified data are stored at predetermined memory locations on the system to deter 
unauthorized access of the digital content data. 

In a preferred embodiment, it is determined whether an unauthorized attempt 
at accessing the digital content data occurs, and in the event of unauthorized access, 
saturation traffic is gaierated on the system to deter flie unauthorized activity. The 
saturation traffic may comprise 

commands that burden system resources, for example as a fimction of activity 
utilizing the system resources subject to the unauthorized access. 

The present invention is further directed to a mefliod and system for 
preventing unauthorized use of distal contesnt data hosted on a system wherein a 
table of contents identifies files stored at memoiy locations of the system. A first 
memory location referring to a location at which at which first data file is stored is 
identified at the table of contents. The first memory location in the table of contents 
is then modified to refer to a second data file at a second location, Upon an attempt 
at access by the system of the first data file, the second data file is accessed if the 
attempt is unauthorized. 

In an altemative anbodiment, the first data file is replaced with the second 
data file and upon an attempt at access by the system of the first data file, the second 
data file is accessed if the attempt is unauthorized. 

The present invention is further directed to a method and system for 
preventing unauthorized use of digital content data hosted on a system. An operating 
system interface of the system is monitored to determine access of operating system 
resources. A shim is repeatedly generated on the operating system interface to deter 
unauthorized access of the digital content data. 

' The present invention is further dkected to a method and system for 
preventing unauthorized use of digital content data hosted on a system wherein a 
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portion of the digital content data is substituted with token data to generate tokenized 
data. The tokenized data are stored at predetermined memory locations on the 
system to deter unauthorized access of the digital content data. 

The present invention is further directed to a method and system for 
preventing unauthorized use of digital content data hosted on a system wherein an 
operating system mterface operating on the system and the digital content data at an 
assassin process are monitored to determine whether an unauthorized attempt at 
accessing the digital content data occurs. In the event of unauthorized access, the 
unauthorized access is deterred and communicated to the operating system interface. 

The present invention is further durected to a method and system for 
preventing unauthorized use of digital content data in a system having memory 
locations wherein the system is scanned to deteraiine available memory locations 
based on a file system identifying locations of files oh the system. Target memory 
locations are determined within the available memory locations at which to store the 
digital content data. The digital content data is stored at the target memory 
locations. 

In another aspect, the present invention includes a software development kit 
and toolkit, which embodies the aspects of the inventions described above and 
allows for thek application to target content without revealing the details of the 
construct methods to the user. 

The present invention is thus fiirther directed to a system for preventing 
unauthorized use of digital content data in a system having memory locations 
wherem the system enables a user to select fi-om aplurality of tool modules, each 
module providing a service for protecting digital content from unauthorized use such 
. that a user can protect digital content. The tool modules may comprise modules that 
perform functions selected from the group of functions consisting of: interieaving; 
tokenization; obfiiscation; saturation; translocation; shimming and assassination. 

The present invention is fiirther directed to systems and methods that allow 
for the delivery of content in a feshion that prohibits content modification and 
dupUcation by unauthorized persons. The invention mechanisms detaUed in this 
document enable, support and secure the delivery of software tities, audio, video, and 
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text/graphic/e-book/e-presentation fonnats using both hard media and network 
content delivery models. 

The present invention further processes and packages the components of a 
digital content product, for example the standard component contents of a hard 
media digital product, including executable files, documentation files, image files, 
and audio files. A standard hard media product may be taken in entirety from a CD 
release and converted into a securely downloadable product. Some or all of the 
content is indelibly watermarked with seriaUzed purchase information unique to each 
purchaser at the download site before being downloaded. On a server that deploys 
this protected content, kit components can be packaged as large archives or can be 
stored individuaUy (in the same form as a hard media kit, including optionally, 
directory stractures) and then manufactured on-demand, per-user, per purchase. The 
final kit is packaged as a collection of encrypted archives, or as a single monolithic 
archive, securely encrypted, and made installable at the appropriate time by a secure 
installation process. Each installation of the product can optionally be made more 
secure by requiring authentication; multiple invention methods may be used 
including network authentication and authentication from locally hidden data and/or 
local computing device and peripheral configuration information. In the network 
installation case, installation or re-installation may be disallowed at any time by the 
vendor based on then: criteria (number of times, frequency, etc). Such remote 
authentication invention methods may be added to hard media based products as 
well. 

The present invention fiirther allows for modification of the product's files, 
both before the download while still on the server (or before being copied to the 
server), and also the application files in the product directory after the installation, on 
the customer computer. This invention inserts hidden data into tiiese product files, 
this hidden data incorporating among other identifying data a securely encrypted 
transaction ID, which may also be modified by a function based on information 
about the target system's component-specific configuration information. The hidden 
data may alternately or inclusively be a simple numeric index or may also have 
meaningfiil content interleaved into itself, such data hiding concepts defined herein. 
The data maybe of any length. These hidden data items are inserted into secret 
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locations within the product files prior to kitting, for example using the mechanisms 
disclosed hea^in, at the point of purchase. 

The present invention further authorizes the execution of product components 
by providing a service that correlates attributes of the executable product with the 
system which is the target of the execution of the product. This applies to hard media 
and to Electronic Software Distribution (BSD), hi this aspect, the BSD content 
delivery phase may be authenticated by means of purchase (or other) unique 
transaction-specific information and/or system specific information. 

The present invention further processes product files in order to make room 
for more hidden data items. These additional reserved spaces for hidden data items 
are integrated directly into any desired product files and are optionally pre-filled 
with filler content 

The present invention fiarther segments the contents of the download kit such 
that specific'small and critical files or even portions of such files are segregated firom 
the main kit. The downloaded installation kit is therefore incomplete in small but 
critical ways. The installation process requires subsequent authenticated 
reconnections to the download host, followed by small and volatile downloads of 

these aitical items, 

•The present invention fiorther segments the contents of the installed digital 
product such that specific critical files and/or portions of such files are segregated 
and encrypted in a fashion that makes the installed product only fimction properly on 
the uitended target system. 

According to the present invention, certain chosen program elements are 
intentionally mcomplete, and will be completed by means of executable infomaation 
extracted from the authorization process, in some cases by hiding the information 
within the authentication response. For example the authorization process can 
provide tiie system with both numerical encrypted information (keys for fiffther 
system decryption use) and executable content critical to task completion. 

According to the present invention, content has certain sections altered such 
that key elements are removed and hidden elsewhere, (on die media itself in the case 
of hard media, on the network in other cases, on other system storage devices in the 
case of something ahready installed on a computer system) in secret locations. 



wo 03/029939 PCT/USOl/44045 

-12- 

Execution requires these hidden elements be found and replaced in their original 
locations within the content. These elements are stored in locations that would not be 
copied easily with either the installer media or the installed product directory. 

The present invention is fiirther directed to mechanisms that detect the 
presence of classes and instances of software development tools (known variously as 
ICES, Debuggers, dump/lift tools, process fixup tools) and which initiates responses 
(exit, kill intrusion process, etc) when invoked on a system that has been thus 
instrumented for hacker purposes. 

The present invention further determines whether the environment is safe 
(criteria include absence of some or all software development tools and emulation 
environments) and aUows the protected title, to run. After this occurs, subsequent 
execution of any and all prohibited tools is disallowed in part this is accomplished by 
means of methods discussed in the Translocation claims attached herein; by 
translocation of the desired tool with a stub that exits. Other methods include 
disabling certain input device (keyboard and mouse) responses as needed. 

In another aspect, in order to defend the system from attack, the system exits 
upon being compromised or otherwise touched by unauthorized tools or methods. 
The exit itself may be delayed or deferred to obfuscate the logic behind the exit 
process. Other cooperating components of the invention (processes, threads, tasks 
and other logical algorithmic entities) can be configured such that if one exits for any 
reasons all the others exit as well. 

In another aspect, all system defense related tasks (such as encryption, 
decryption, message passing, debugger detection via memory scan, etc) are 
encapsulated within other routines commonly used by the system. For example, it 
can be that every file open also triggers a defensive routine that scans memory or 
rewrites memory, to this manner, any and all system activity act as events that trigger 
defensive routines, so these routines do not necessarily have to poll or loop as their 
exclusive method of acting upon the sj-stem. Removal of these defenses is non- 
trivial as they can be deeply integrated into every aspect of the system. 

In another aspect, each process, thread or task in the system has a dual or 
multiple role. One is the true fimctional role of that component (such as decryption), 
and the other is the monitoring and protection of all other parts of the system u^g 
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techniques outlined in this docunxent. Such protective functions are sometimes 
referred to as Assassin processes. Any attempt to compromise the system will result 
in a mass exit of all system components. The distributed nature of this protection 
across dozens of system tasks results in a very powerful redundant protection model 
where any attempt to tamper with one part of the system results in a protective 
response from the rest of the system. 

In another aspect, all strings and other resource elements used are encrypted 
and decrypted by the system in a volatile fashion when used, and then disposed of, 
such that they cannot be easily searched for within the code either statically or m 
memory. 

In ano&er aspect, data values that are critical to the system are read and 
rewritten by a n\mber of decoy or spoof processes, such that debugger \yatchpoints 
on these values, if any, will be triggered excessively, and thus it will be difficult to 
determine which accesses are decoy and which are valid without much deeper 
debugging. 

In another aspect, system and product code can maintain itself in a difficult- 
to-modify state even if modification is attempted by a sophisticated debugger, editor 
or other tool. Key code elements are rewritten in place, in memory, using whatever 
mode of privilege is required, many times per second (tens, hundreds, tuned to be 
optimal as needed), at initialization and during execution, so that any attempts to 
tamper the code will be changed back to the original state. Depending on the nature 
of the change, the system may also choose to exit as a result of the tampering. For 
example, a classic hacker attack, the modification of hnport Tables, is defeated in 
this way. All key code segments are duplicated in an encrypted archive, the archive is 
hidden (perhaps within fUes, between files, or outside the file system) read from that 
archive (some part of the read and decryption occurs in the virtual machine context 
described elsewhere in the document). Decoy archives and decoy read processes are 
also estabUshed which read from nonencrypted decoy code and write it over the 
sections, or seem to write it over the sections (writes through the I/O subsystem 
which are then defeated by tapping into the subsystem and tossing the data away) 
such "that attempts to modify these decoy archives result in no change to the running 
code. 
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In another aspect, certain critical executable components are processed before 
shipment to be populated with tens or hundreds of thousands of data values which 
trigger debugger breakpoints in many debuggers. During normal execution of the 
title in a non-debug environment, these breakpoints are handled by a null handler and 
little negative performance impact is achieved, hi the debug environment, each 
breakpoint stops the debugger and requires the intruder to at the least click the mouse 
and type into the keyboard. A single execution of such a titie would require on the 
order of a hundred thousand mouse-clicks and keyboard presses. The purpose of 
such is to significantly deter unauthorized debugging, and at the very least to render 
it as slow and painful as possible. 

In another aspect, resistance to tools used to "memory Uft" or •'memory 
dump" is achieved by modifying (corrupting) large parts of the code before 
packaging and storing the original correct parts elsewhere. This modification can 
take the form of gross and/or subtle corruption, yielding unexecutable code or subtie 
logical alterations in code that runs. When tiie code is run in the correct context, a 
cooperating synchronized system process modifies the code back to the correct 
executable state but only in a rolling window of context such that at no time is the 
entire body of the content correct, just those parts that are required at the current 
execution time. Once executed these lines of code are re-coirupted. 

hi another aspect, source, object, or executable code is processed to generate 
variant different versions of executable code, by means of replacement of content 
with functionally synonymous content. For example in the case of executable 
content, different assembly language instructions and ordering, that produce the same 
functional outcome,are generated, such that no two such versions share the same 
fingerprint or the same code-line-number relationship per instmction. This variation 
is designed to reduce or eliminate the broadly disseminated effectiveness of hacker 
tiitorials and documents that usually depend on specific line-number directions. 

Brief Desc ri ption of the Drawings 

■ The foregoing and other objects, features and advantages of the invention will 
be apparent fiwm the more particular description of preferred embodiments of the 
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invention, as illustrated in the accompanying drawings in which like reference 
characters refer to the same parts throughout the different views. The drawings are 
not necessarily to scale, emphasis instead being placed upon illustrating the 
principles of the invention 

FIG. 1 is a block diagram of a computer system or consumer computerized 
appliance device to provide an understanding of how the systems and methods of the 
invention interact with such devices. 

FIG. 2 is a diagram demonstrating the flow of digital content from its 
delivery media through a computer system such as the one in FIG. 1 , in accordance 
with the present invention. 

FIG. 3 is a flow diagram that describes the creation of an interleaved, 
multiplexed, encrypted content stream such as those used for information hiding and 
content watennarking, in accordance with the present invention. 

FIG. 4 is a block diagram illustrating the placement of hidden, stored content, 
in accordance with the present invention. 

FIG. 5 is a block diagram illustrating an alternative or additional placement 
method for hidden, stored content, in accordance with the present invention. 

FIG. 6 is a flow diagram illustrating the storage of digital content in a hidden, 
secure manner, in accordance with the present invention. 

FIG. 7 is a flow diagram illustrating a method for retrievmg such hidden, 
stored content, in accordance with the present invention. 

FIG. 8 is a block diagram illustrating four related methods of securing an 
encrypted watermark or encrypted stream, in accordance with the present invention. 

FIG. 9 is a block diagram illustratmg three related methods for translocating 
content in a secure fashion, in accordance with the present invention. 

FIG. 10 is a flow diagram that illustrates a method to prepare content for 
translocation, in accordance with the present invention. 

FIG. 1 1 is a flow diagram illustrating a method to invoke and utilize 
translocated content, in accordance with the present invention. 

FIG. 12 is a flow diagram illustrating a method to tokenize and obfuscate 
content, in accordance with the present invention. 
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FIG. 13 is a detailed flow diagram illustrating a method to tokenize and 
obfuscate content, in accordance with the present invention. 

FIG. 14 is a further detailed flow diagram illustrating a method to tokenize 
and obfuscate content, in accordance with the present invention. 

FIG. 1 5 is a high level flow diagram illustrating a method to utilize 
previously tokenized and obfuscated content, in accordance with the present 
invention. 

FIG. 16 is a detailed flow diagram illustrating a method to utilize previously 
tokenized and obfuscated content, in accordance with the present invention. 

FIG. 17 is a flow diagram illustrating a method to saturate logging and 
debugging tools and techniques as a method of providing additional" security, in 
accordance with the present invention. 

FIG. 18 is a detailed flow diagram describing a method to saturate logging 
and debugging tools and techniques as a method of providing additional security, in 
accordance with the present invention. 

FIG. 1 9 is a further detailed flow diagram describing a method to saturate 
logging and debugging tools and techniques as a method of providing additional 
security, in accordance with the present invention. 

FIG. 20 is a detailed control flow diagram describing a method to saturate 
' logging and debugging tools and techniques as a method of providing additional 
security, in accordance with the present invention. 

FIG. 21 is a flow diagram describing the aspects of this invention that allow 
for the secure attachment (hooking) of device shims, operating system shims, and 
device driver shims, in accordance with the present invention. 

FIG. 22 is a flow diagram describing the aspects of this invention that allow 
for the security obfuscation of the activity of device shims, operating system shims, 
and device driver shims. 

FIG. 23 is a flow diagram describing a mechanism used to prevent the 
execution of, or access to, content that is disallowed, or to redirect access to other 
content in a fashion transparent to the accessing party or process, in accordance with 
the present invention. 
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FIG. 24 is a flow diagram that illustrates a method for the creation of 
protective "assassin" processes, in accordance with the present invention. 

FIG. 25 is a flow diagram that describes methods that determine authorization 
for access to content, in accordance with the present invention. 

FIG. 26 is a flow diagram that describes methods that determine authorization 
for access to content, in accordance with the present invention. 

FIG. 27 is a flow diagram of a method that takes as input the standard 
contents of a digital hard media product (including but not limited to software, e- 
books, entertainment and game media, etc) and produces as output a securely 
downloadable digital content product, in accordance with the present invention. 

FIG. 28 is a flow diagram of a method that estabhshes the unique identity of 
the Target Computing device, in accordance with the present invention. 

FIG. 29 is a flow diagram of a method that processes digital content 
components as part of the kitting process for electronic content distribution, in 
accordance with the present invention. 

FIG. 30 is a flow diagram of a method that assigns unique identi^ng values 
to individual subcomponents of the Target Computing device, in accordance with the 
present invention. 

FIG. 31 is a flow diagram of a method that inserts unique identifying data 
into digital content product components, in accordance with the present invention. 

FIG. 32 is a flow diagram of a method that authenticates access to and use of 
digital content by verifying unique identifying data found within the digital content, 
in accordance with the present invention. 

FIG. 33 is a flow diagram of a method that provides authentication data to the 
method of FIG. 32, in accordance with the present invention. 

FIG. 34 is a flow diagram of a method that creates additional space within 
digital content for the later insertion of unique identifying data, in accordance with . 
the present invention. 

FIG. 35 is a flow diagram of a method that inserts unique identifying data 
into digital content on a server, using such created locations as those created in the 
flow diagram of FIG. 34 or other space as found within the content, in accordance 
with the present invention. 
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FIG. 36 is a flow diagram of a method that inserts xmique identifying data 
into digital content as it is being installed onto a Target Computing device, using 
such created locations as those created in FIG. 34 or other space as found within the 
content, in accordance with the present invention. 

FIG. 37 is a flow diagram of a method that renders incomplete and thereby 
prohibits execution of or use of digital content on systems other than those 
authorized to execute it, in accordance with the present invention. 

FIG. 38 is a flow diagram of a method that encrypts and hides unique system 
and acquisition transactional identifying information, in accordance with the present 
invention. 

FIG. 39 is a flow diagram of a method that scans memory on a Target 
Computing device to deteimine whether certain prohibited executable applications, 
tools, and files are present, in accordance with the present invention. 

FIG. 40 is a flow diagram of a method that determines whetha: the system is 
an actual or virtual computing device, in accordance with the present invention. 

FIG. 41 is a flow diagram of a method that disables the use of certain 
keystroke sequences, in accordance with the present invention. 

FIG. 42 is a flow diagram of a method that disables the keyboard entirely 
when desired for certain input window or dialogue focus configurations, and 
selectively allows it for others, in accordance with the present invention. 

FIG. 43 is a flow diagram of a method that disables mouse button fimction 
entirely when desired for certain input window or dialogue focus configurations, and 
selectively allows it for others, in accordance with the present invention. 

FIG. 44 is a flow diagram of a method that detects compromise of the system 
in the form of the exit of other system components and which itself then initiates a 
cascading exit event, in accordance with the present invention. 

FIG. 45 is a flow diagram of a method fliat allows cooperating system 
component to more securely write data to one another, in accordance with the present 
invention. 

FIG. 46 is a flow diagram of a method that allows cooperating system 
component to more securely read data from one another, in accordance with the 
present invention. 
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FIG. 47 is a flow diagram of a method that allows cooperating system 
component to more securely write data to one another, using further levels of 
indirection than those shown in FIG. 45, in accordance with the present invention. 

FIG. 48 is a flow diagram of a mefliod that embodies security or security 
system functions within any standard system function, in accordance with the present 
invention. 

FIG, 49 is a flow diagram of a method that embodies exit functions as in FIG. 
44 within any standard system function, in accordance with the present invention. 

FIG. 50 is a flow diagram of a method that converts system resources such as 
strings into encrypted resources to reduce their search vulnerability and 
comprehension, in accordance with the present invention. 

FIG. 51 is a flow diagram of a method that renders encrypted resources such 
as those created in FIG. 50 usable as needed, in accordance with the present 
invention. 

FIG. 52 is a flow diagram of a method that touches many memory locations 
in order to generate excessive debugger event traflSc, in accordance with the present 
invention. 

FIG. 53 is a flow diagram of a method that overwrites data in memory with 
such rapidity and frequency that attempts to alter this in memory data via 
unauthorized means are eradicated automatically, in accordance with the present 
invention. 

FIG. 54 is a flow diagram of a method that inserts a number of brealqpoints 
into target digital content in order to render unauthorized debugging extremely 
difficult, in accordance with the present invention. 

FIG. 55 is a flow diagram of a method that protects digital content from being 
memory lifted by creating a 'tolling window of corrected code" in an otherwise 
corrupted body of digital content, in accordance with the present invention. 

FIG. 56 is a flow diagram of a method that creates multiply variant digital 
content, in order to increase the difficulty of cooperative debugging and cracking of 
digital content when deployed, in accordance with the present invention. 
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Detailed Description of Preferred Embodiments 

The present invention will be more completely understood by means of the 
following detailed description, which should be read in conjunction witli the attached 
drawings, FIG.l through FIG. 56, in which similar reference numbers indicate 
similar structures. 

This invention and its embodiments may be implemented on a personal 
computer or general purpose digital computer as shown in FIG. 1, including, but not 
limited to, single- or multiple-processor-based Windows, Linux or Macintosh 
desktop computers such as those found with increasing frequency in contemporary 
homes and offices. Embodiments of this invention may also be implemented on a 
digital processing circuit, including, but not limited to, those found in CD and DVD 
consumer audio/video appliance components or systems, stationary or mobile 
applications. Embodiments of this invention are also well suited for implementation 
on other computing appliance devices such as hard-disk or random access memory 
based video and audio entertainment appliances which maybe digital-processing- 
circuit based, or may be based on general-purpose digital computing architectures. 
As can be made clear to one skilled in the art, this invention is applicable to all 
digital content uses, because all such uses have the same basic elements; the content 
7 is input to the system in some fashion as shown in FIG. 2, stored for some period 
of time in the system's memory 8 (whetha* disk, volatile RAM of any kind, or non- 
volatile RAM of any kind), and executed on a processor 9, whether the main 
processor of the system, or an auxiliary processor, and whether the content itself is 
directly executable on the processor or is executed within a helper application (such 
as an audio, video, or word processing application, depending on content type). 

The systems and methods of the present invention maybe embodied and 
implemented on a general-purpose digital computer or personal computer system 6 
as shown in FIG.l. Such a system commonly includes an input device 1 (one or 
more may be connected; this includes anything which provides extemal content and 
data to the computer as input, such as a mouse or keyboard or scanner). Such a 
computer system 6 also has as a subcomponent a collection of software and hardware 
components 5 tiiat comprise the processor, all system bus and cache lines, and the 
running operating system and all of its subcomponents. Output is presented to the 
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user via one or more output devices 4, which include, but are not limited to, the 
computer's display (CRT or LCD) and the hardware that drives it, and can also 
include printers, speakers and sound cards, and radio frequency, S-video, component, 
or digital video outputs for consumer/entertainment applications and devices. 

The computer system 6 maybe a general purpose home or office or mobile 
computer system. Such systems allow for the usage/consumption/execution of a 
variety of forms of digital content; the invention disclosed herein can be appHed to 
all forms of such digital content and the foregoing will describe some of the forms of 
this content on this computing platform family. Such systems are generally multiple- 
component level hardware-based systems, comprised of a motherboard or main- 
board, with various specialized components (such as I/O cards, video cards, 
processors, memory) attached to it by means of connectors. Each such card and the 
motherboard itself and the attached components have some amount of executable 
firmware located on various non-volatile memory 3 integrated circuit components, 
but the majority of the system's operational logic is driven by executable operating 
system code that is stored on media (non-removable or removable magnetic and or 
optical media, or non-volatile random access memory media). Usually on a system of 
this general type such executable code is created by software developers and is 
written using program code in modem programming languages such as C and C++. 
Such languages are programmatically compiled into assembly language or machine 
instruction code and are later executed directly on the system's central processing 
unit. Other programming languages and techniques, such as those used in Java, 
JavaScript, and Visual Basic, are interpreted at runtime; they're stored in their 
original language, or in a moderately tokenized version of their original language, 
and are then rendered on the fly at execution time into assembly language or machine 
instruction code and are later executed directly on the system's central processing 
unit. Other forms of relevant digital content utilized on such a computer system are 
audio (for example .wav or .mp3 file formats), video (for example .avi file format), 
e-book and documentation (for example .pdf or variant secure-portable-document- 
fomat), and all such content maybe significantly security-enhanced by the 
application of the invention described in this document 
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As shown in FIG. 2, a computing system 10 of any kind, whether a general 
purpose computer 6 (see FIG. 1) or an appliance device with computing capability 
and components (such as a DVD or CX> player) is commonly used to consume, 
execute, display or otherwise utilize digital content Digital content 7 (including but 
not limited to the above examples) is made available to the system by a variety of 
means including by network transmission (intemet or intranet), on hard media, on 
non-volatile random access memory removable storage (such as the compact flash 
standard for removable media storage cards); and is read from that media 7 into the 
system's memory 8. hi the case of such content which is unprotected, the utiUzation 
model is straightforward; it is read from the input media 7 into memory 8 and then 
executed at some point thereafter. This document will defme the word "executed" to 
mean, in the case of binary executable program content (for example a computer 
video game, or a game console video game running on a game console computing 
^pliance device, or a word processing program intended to run on a general purpose 
computing device), executed on the processor 2 as a program; in the case of readable 
document formats (for example a Word .doc file or an Acrobat .pdf file) executed 
within the appropriate application, which in turn executes on the processor 2 as a 
program; in the case of all other digital content types (for example audio, video) they 
too are intended to be mput to an appropriate apphcation (for example on a general 
purpose computing device, a software application such as Windows Media Player; in 
the case of a computing appliance device such as a DVD player or a game console, a 
firmware executable which runs on a processor 2 within the computing appUance 
device) which in tum executes on a processor 2 within the computmg platform. Also 
note that within this document the tenn "stream" may be used interchangeably with 
the term "filtf' to represent a collection of bits that represent some form of digital 
content, including not limited to standard file types found on operating systems such 
as Windows and archive or container formats used to convey content on the intemet 
such as "ZIP" files or "TAR" files. 

hi one embodunent of this invention, illusfrated in FIG. 3, an interleaved- 
multiplexed data hiding process 19 (optionally, also, an excellent framework for the 
application of encryption to the interleaved, multiplexed content) is provided that 
performs multiple fimctions detailed in the foregoing paragraphs. The system and 
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process of the present invention create meaningful (optionally encrypted) data- 
identifier tags, sometimes referred to as watermarks, for later insertion into content, 
of any desired size in number of bytes, each of which have an individual variation 
even when the identifier data is identical for each. Data content is first input as 
shown in step 1 1 . Watermarks are defined as composed of a variable number of bits 
12. These collections of bits are re-ordered as needed and interleaved at step 13 with 
other data, that is either randomly generated, or time-stamped, to create a unique 
numeric value. Alternatively, the collections of bits can be interleaved at step 13 
with data streamed directly fi-om other portions input data content 11 itself, to be 
hidden in the watermark. A simple verification value is incorporated into the 
watermark data or the interleaved-multiplexed data stream such that any instance of a 
watermark maybe examined to detranine if it has been tampered with. Following 
this, the resultant stream is output and written to predetermined memory locations at 
step 1 8 either at locations as selected in tiie mapping process outlined elsewhere in 
this document or any other locations specified by the system. 

Prior to writing the output stream, the watermark may optionally be encrypted 
by a key to fiirther enhance its security. The encryption key itself can also be 
optionally encrypted in a similar manner in steps 15 (subdivide into segments) 16 
(interleave) and 17 (encrypt), and optionally stored in a known location with the data 
stream 18. 

An example of the resultant effect of the system and method of the invention 
is provided in the following illustration. Assume an identifier 1234 11 that is to be 
hidden in 100 locations on a game CD (see description below in connection with 
FIG. 6, FIG. 7, BIG- 8 for details related to where and how the invention elects to 
hide such data). Assume also a subdivision size of 8 bits, and a total number of 
streams to be interleaved at 2 streams. The example of this method takes the bytes 
of the identifier, in this case the bytes "1", "2", "3", and "4" 12 and interleaves them 
with a second stream of bytes 13. These four divided subcomponents are then 
interleaved 13 with some other data; in this example the data comes from the text of 
this sentence beginning with 'These four divided" 11. Thus the first watermark 
generated would be "Tlh2e3s4" 13 and the second watermark would be "el 2f3o4" 
13. Even in this simple form it is clear that the two watermarks have a different 
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appearance and would not be trivially searchable; however when optionally 
encrypted at step 14 they become utterly dissimilar, yielding the values "art6G2.R" 
and ">*qIlUb$" in this example; these two values, hidden (see FIG. 6) or stored in 
the file system (see FIG. 4) would be quite secure, yet each is easily beatable by 
means of this invention (the location process is described with refer«aice to FIG. 7, 
below), and once located, each is easily translatable using the invention componaits 
described with reference to FIG. 7 back into the identifier "1234". 

The present invention, illustrated in FIG. 3, also serves as a means of 
interieaving N streams of data for purposes far more general, and more broadly 
useful, tiian simply watermarking content. It can irrevocably intermix 13 multiple 
streams 11 of content such that they remain interleaved until utilized by an 
appropriate component of the present invention, as illustrated in FIG. 7, below. 

The foUovdng code example details an embodiment of tibis invention which 
illustrates the concepts discussed in the above paragraphs which reference FIG. 3. 
This embodiment is tuned to subdivide a stream of data into 8 bit bytes and then 
interleave them; in practice, any number of streams maybe subdivided, and any 
subdivision value maybe used. 



// Return a sig 
BOOLEAN CSig6en::GetSig( 
const BYTE*const inp_bld, // sig data 
const unsigned int in_cbld, // length of sig data 
BYTE'const outp_bSig, // generated sig, SigSize() bytes 
const DWORD in_dateTime, // The date time bytes 

const int in_sigToggle // Doubie the size of a watermarl< 

) 

^ BYTE abJumbie[iVIAX_SIG_SiZE];// buffer jumble dat 
BYTE abSigRaw[MAX_SiG_SIZE]; // buf for in-process sig 
BOOLEAN bStat; 
unsigned int cbJumb; 

unsigned int cbSig = SigSizeO; // size of gen'd sig 
unsigned int ii; 
unsigned int ilotal; 
unsigned int jj; 

unsigned int cbld = min(SigSize()/2, in_cbld); 



// Validate args 
if{(NULL==outp_bSig) |1 

(cbld > cbSig) 1| 

(IVlAX_SiG_SiZE < CbSig) |1 
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{(in^sigToggle == 1) && (in_cbld < 2*cbld))) 

{ 

return FALSE; 

} 

5 

// Get the jumble data we need 

cbJumb = (cbSig - cbid) - 1 ; // subtract 1 for checksum 

if (!m_pJumbler->GetData(cbJumb, abJumble)) 

{ 

10 return FALSE; 

} 

// Compute the simple verification value of the data 
iTotal = 0; 

15 for(il = 0;il<cbld;ii++) 

iTotal += (unsigned int)(inp_bld[ii + in_sigToggle*cbld]); 
abJumble[cbJumb] = (BYTE)((unsigned int)OxOOFF & iTotal); 

20 

// Interleave if the sizes are right 
rf(cbld==cbSig/2) 

{ 

for (ii = 0; ii < in_cbld; ii++) 
25 { 

jj = 2*ii; 

abSigRawDj ] = lnp_bid[ii + ln_sigToggle*cbId]; 
abSigRawfij + 1] = abJumblepi]; 

30 ^ if ((in_dateTime) && (cbSig >= 1 6) && {in_sigToggle == 0)X 

// Instead of using random data, use the date/time bytes 
abSigRaw[1] = (BYTE) (in__dateTime & Oxff); 
abSigRawIS] = (BYTE) ((in^dateTime & OxffOO) » 8); 
abSigRaw[9] = (BYTE) ((in_dateTime & OxffOOGO) » 16); 

35 abSigRaw[1 3] = (BYTE) ((in^dateTlme & OxffOOOOOO) » 24); 

else if ({CbSig >= 16) && (in^sigToggle == 1) && (in_cbld = cbld*2 + 4)){ 
// Instead of using random data, use the date/time bytes 
abSigRaw[1] = inp_bld[16]; 
40 abSigRaw[5] = inp_^bld[1 7]; 

abSigRaw[9] = inp_bld[18]; 
abSigRaw[13] = inp„bldI19]; 

} 

45 } 

// Otherwise, tack the jumble data on the end 

else 

{ 

50 memcpy(abSigRaw, inp_bld, cbId); 

memcpy(&(abSigRaw[cbld]), abJumble, cbSig - cbId); 

} 

// Now encrypt it 

55 bStat = m_pEncryptor->EncryptBlocl<(abSigRaw. outp^bSig); 

// Zero the in-process sig data 
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memset(abSigRaw, 0, sizeof{abSigRaw)); 

// Done 
return bStat; 

} // End GetSigO 

A simple example and embodiment of ttiis aspect of the present invention 
now follows. Assume three streams of digital content, in this case tfiree ffles on disk, 
each of five megabytes in size. File "A" is a text ffle. File *'B" is an audio file. FUe 
"C" is a Word document; thus on a general purpose computing device 6 (see FIG. 1) 
Windows operating system this yields the three hypothetical input streams 11 derived 
from A.txt, B.wav, C.doc. Each such stream is subdivided into segments of M bits in 
length 12, and interleaved as in the previous example. The resultant output, even 
prior to encryption, is clearly incomprehensible to any mechanism other than this 
invention (see, for example, the operation disclosed in FIG. 7) due to the nature of 
the mixed text, audio, and document data. Even so, the output itself may be 
encrypted as in FIG. 3, steps 14, 15, 16 to further protect its contents. The 
aggregate stream is optionally encrypted, and then the keys necessary to decrypt this 
stream, if encrypted, are themselves encrypted and hidden; the manner of the hiding 
process maybe as described in FIG. 8, examples 42, 43, 44 or 45, described in detail 
below, or the key may be hidden in another location known to the system as needed. 
This aggregate multiplexed stream, now fiifteen megabytes in size may be written 18 
at this tune. 

One embodiment of the writing process 18 streams the contents back into the 
origmal files A, B and C (see FIG. 6 and corresponding description) from where they 
came, without regard for which contents came from which files, such that the first 
five megabytes of the fifteen megabyte stream is used to fill A.txt, the second five 
megabytes is used to fill B.wav, and the third five megabytes is used to fill C.doc. 
The method used to determine where to write, to keep track of whare the data was 
written, and to record the manner in which it was interleaved, is detailed below with 
reference to FIG. 6. After having written the content, the present invention supports 
multiple techniques for providing that the data may be later read and de-interleaved 
properly (see FIG. 7, below). Note that the concept of a map of locations and 
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interleaved data information as detailed in FIG. 7 40 is optional for purposes of this 
aspect of tiie present invention. The map can be incorporated into the stored, hidden 
content, or as an alternative embodiment of the invention, algorithmic logic identical 
to that described below in FIG. 6, with the order of execution as in steps 27, 28 
(described below) is incorporated into the process of the present invention such that 
the likely map locations can be determined based on the context and content of the 
media. The retrieval of segments of the stream can then be attempted the simple 
verification values calculated as shown in the code example above to determine that 
the correct data has been retrieved. The stream contents can be retrieved, decrypted, 
de-interleaved, and utilized. 

The following example CmapLocation::WriteFile is a code example of the 
logic used to create such a map file of locations. Note that there are two types of 
maps created by the CmapLocation::WriteFile code example below: raw maps and 
location maps. Raw maps are built upon a linked list structure of locations and 
lengths and also contain detailed information about the file this mapped area was 
derived fi-om. Location maps are a finther abstraction, and are built upon linked lists 
of raw map hsts, where each location map entry contains information to locate a 
certain number of data bytes. In the example code below, this value is 1 6 bytes to 
support the example encryption method, which is optimized for 16 bit units of data. 
So in the foregoing example, the location map is created firom the raw map by 
partitioning it into 16 byte blocks. These 16 byte blocks need not be contiguous. 

Also note that the following code examples embody another aspect of this 
invention; namely, a file locker, a mechanism as described below with reference to 
FIG. 8 and touched upon in FIG. 3 steps 15, 16, 17. The file locker serves to 
securely marry the decryption key to an encrypted stream such that the process 
described in FIG. 7 can successfiilly unlock the data and decrypt it. The file locker 
further encrypts the encryption key using a secondary encryption algorithm, witiii a 
known key, and hides the key information within the encrypted stream as described 
below with reference to FIG. 8. The encrj'pted key may be hidden whole (as in steps 
42, 43, and 44 of FIG. 8) or maybe further subdivided and hidden in a scattered 
fashion (as in steps 45, 46, 47, 48, 49, and 50 of FIG 8). 
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CMapLocation::WriteFile( 
const char*const mapFileName 

) 

LocationMapList * pos = locationMapList; 
MapRawLlstJ * rpos; 
BYTE output[512]; 
CFileLock *fileLocker; 
C2Encryptor *fileEncrypt; 
CREncryptor *fileLock; 
BYTEkeyI16); 
int i; 

unsigned long j; 

WORD majorVersion = H1W0RD(MAP_L0C_VERSI0N); 

WORD minorVersion = L0W0RD(MAP_LOC_VERSION); 

// Encryption Locker 

fileLock = new CREncryptor(MAP_LOC_KEY); 
// Generate Random key 
srand( (unsigned)time( NULL ) ); 
for (i=0;i<16;i++){ 

key[i] = (char) (rand() / (RAND.MAX / 255)); 

} 

fileEncrypt = new C2Encryptor(key, 16); 
if (mapFileName) 

^ fileLocker = new CFileLock(fileEncrypt, key, 16. fileLock, majorVersion, minorVersion, 
(char *) mapFileName); 
} 

else 

fileLocker = new CFi!eLock(fileEncrypt, key, 16, fileLock, majorVersion, minorVersion, 
"c:\\l.tmp"); 

} 

// Write out location size 

fileLocker->WriteBytes((BYTE *) &(locationSi2e), sizeof(locationSize)); 

while (pos && pos->locNumber) 

if ((pos->!ocation->length == locationSize) && (pos->Iink) && 
(pos->link->location) && (pos->iink->location->length == locationSize) && 
((pos->location->offset + pos->location->length) == pos->Iink->location->offset)) 

{ 

// Run of location map entrys 
output[0]=_MARKER; 
output[1] = LOCMAPRUN; 
fileLocker->WriteBytes(output,2); 

fileLocker->WriteBytes((BYTE *) &(pos->location->offset), si2eof(pos->location- 
>offset)); 

1 = 2; 
: pos = pos->link; 

while ({pos->location) && (pos->location->length == locationSize) && (pos->link) && 
(pos->link->location) && {pos->link->locatlon->length == locationSize) && 
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((pos->Iocation->offset + pos->location->length) == pos->llnk->locatlon->offset)) 
{ 

pos = pos->link; 

5 } 

pos = pos->link; 

// Write out number of entries in this run 
fileLocker->WriteBytes((BYTE *) &0). sizeofC)); 

10 } 

else 

{ 

// Normal location map entry 
output[0] = _MARKER; 
1 5 output[1] = LOCMAPENTRY; 

fileLocker->WriteBytes(output,2); 

fileLocker->WriteBytes({BYTE *) &{pos->locNumber), sizeof(pos->locNumber)); 
rpos = pos->Iocatlon; 
while (rpos) { 
20 if (rpos->length > 0) 

{ 

output[0]=_MARKER; 
output[1] = LOCMAPLOC; 
flleLocker->WriteBytes(output,2); 
25 fileLocker->WriteBytes((BYTE *) &(rpos->offset). si2eof{rpos->offset)); 

fileLocker->WriteByles((BYrE *) &(rpos->length). slzeof{rpos->iength)); 

} 

rpos = rpos->llnk; 

} 

30 pos = pos->link; 

} 

} 

output[0] = 0; 

fileLocker->WriteBytes(output, 1); // Write a null byte out at the end of the file 
35 //to cause read back of file to end 

delete f ileLocker; 
delete fileEncrypt; 
delete fileLock; 

40 } 

CMapRaw::WriteFile( 
const char*const mapFlleName 

45 ) 

MapRawListJ *pos = m_rawMapUst; 
BYTEoutput[612]: 
CFileLock *fileLccker; 
50 C2Encryptor *fileEncrypt; 

CREncryptor *fileLock; 
BYTE key[16]; 
WORD stringLength; 
int i; 

55 WORD majorVersion = HIWORD(MAP_RAW_VERSION); 

WORD minorVersion = LOW0RD([\/IAP_RAW_VERSI0N); 
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// Locker 

fileLock = new CrEncryptor(MAP_RAW_KEY); 
// Generate Random key 
srand( (unsigned)time( NULL ) ); 
for(i=0;i<16;i++){ 

keyp] = (char) (rand() / (RAND.MAX / 255)); 

} 

fileEncrypt = new C2Encryptor(key, 16); 
If (mapFileName) 

^ fileLocker = new CFileLock(fileEncrypi, key, 16, fileLock, majorVersion, 
minorVersion, (char *) mapFileName); 

} 

else 

fileLocker = new CFileLock(fileEncrypt, key, 16. fileLock. majorVersion. 
minorVersion, "c:\\r.tmp"); 

} 

while (pos) 

{ 

if (pos->length > 0) 

{ 

If (pos->name) 

{ 

output[0]=_MARKER; 
• output[1 ] = FILENAMETAG; 
fiIeLocker->WriteBytes(output,2); 
stringLength = strlen(pos->name); 

fileLocker->WriteBytes((BYrE *) &stringLength, slzeof(WORD)); 
fileLocker->WriteBytes((BYTE *) pos->name, stringLength); 

} 

if (pos->fileStartAddress) { 
output[0]=_MARKER; 
output[1] = FILEiNFOTAG; 
fileLocker->WriteBytes(output,2); 

fHeLocker->WriteBytes((BYTE *) &(pos->fileStartAddress). sizeof(pos- 

>fileStartAddress)); 

fileLocker->WriteBytes((BYTE *) &(pos->fileLength), sizeof{pos- 

>fileLength)); 

} 

output[0] = _MARKER: 
output[1] = RAWMAPENTRY; 
fileLocker->WriteBytes(output,2); 

f jleLocker->WriteBytes({BYTE *) &(pos->offset), sl2eof(pos->offset)); 
fileLocker->WriteBytes((BYTE *) &(pos->length), sizeof{pos->length)); 
output[0] = pos->flags; 
fileLocker->WriteBytes(output, 1); 

} 

pos = pos->link; 

} 

delete fileLocker; 
delete fileEncrypt; 
delete fileLock; 
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//fclose(m rawFile); 

} 

With reference to FIG. 4 , the present invention includes a system and 
method by which content can be hidden or stored in a variety of locations, both 
intrafile (within a file) and interfile (between files) and also outside the file system 
on devices that support extra-files system access (such as ISO-9660 CD discs). The 
map files in the code example above detail how such locations are represented and 
communicated. 

The operation for choosing the actual locations will now be described with 
reference to FIG. 5. Note that in FIG. S the extra-file system locations 26, 25 are 
excellent locations to store content securely, because application programs generally . 
camiot access the raw data and are limited to accessing only those data items that are 
located within the bounds of the file system 24 as known to the table of contents 23. 
All appUcation file system accesses through normal interfaces, for example the 
Windows application interfaces to ReadQ, OpenQ, and CloseQ a file, require a file 
handle or descriptor, which means that most applications can only access areas of the 
file system known to the table of contents FIG. 5 23. Thus, on any supported file 
system format, for example ISO-9660, liberal use is made of any extra-file system 
space that may be available. 

With reference to FIG. 6, an aspect of the present invention is disclosed that 
is used to hide or store information in secure or non-obvious locations. In a first step 
of this aspect, the file system is scanned all the possible locations appropriate for 
infonnation hiding are determined 27. Desired locations firom among all the possible 
locations 28 are selected the ordering of insertion into these locations 28 is 
determined. The stream of interleaved data, described above with reference to FIG. 
3, may optionally be encrypted as desired 29. Next, low-level operating system 
interfaces are accessed and device level access 30 is initialized at a level far below 
the normal file system interfaces, such that the device may optionally be addressed in 
any and all valid raw physical locations, whether inside or outside flie standard file 
system. In step 31, the aggregate stream is written across the target locations in the 
order chosen in step 28. An optional map of these target locations may be produced 
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for later access by other aspects of the present invention that may not contain the 
algorithmic knowledge to deteraiine those locations without such a map. 

FIG. 7 is a flow diagram illustrating a method by which the hidden, stored 
content is retrieved, for example infonnation previously hidden in secure or non- 
obvious locations as shown in FIG. 6, In this process, the information is retrieved 
and reassembled into its original form and provided as needed to other system 
components. In detemiining the possible locations where such information could be 
hidden, there are, for example, two possible initial sets of actions 33; either obtain 
the map information previously hidden according to step 28 of FIG. 6, or generate a 
valid retrieval map as an equivalent of the storage map by uicorporating the same 
algorithmic storage logic as rehieval logic, for example the process employed in 
FIG. 6: detemiine all possible locations 27, select the chosen locations and ordering 
28, and create the retrieval map equivalent of a storage map. 

Low-level operating system interfaces are accessed, and device level access is 
initialized 34 at a level far below the normal file system interfaces, such that the 
device may be addressed in any and all valid raw physical locations, whether inside 
or outside the standard file system. The map or map infonnation obtained above at 
step 33 is used to determine the ordering or reading and the read locations, and these 
locations are read in order 35. The items read are concatenated in the order read to 
re-create the original multiplexed interleaved stream. If decrypted previously, the 
decryption key is read, either fi-om the map 33 or from a predetermined location 
which maybe at the beginning of the encrypted stream 43 (see FIG. 8), at the end of 
the encrypted stream 42, at a predetermined offset within the stream 44, or 
subdivided and hidden at predetermined offsets 47,48,49,50 within the encrypted 
stream 45, and is itself decrypted at step 36 of FIG. 7. The stream itself is decrypted 
37 as desired. The stream is de-multiplexed into its component original streams 38. 
Each component stream is subdivided into a number of segments of a predetermined 
number of bits in length and each segment is then de-interieaved 39 into its original 
component input stream. Each such stream is then written to the file system 40 or 
otherwise provided to the system. 

Returning to FIG. 4 the Intrafile space 20, or space within the bounds of a 
file, is space that is usually specified as "unused" or "reserved for future use" in the 
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specifications for the file or stream types. The following list of published 
specifications represent a sampling of those researched to determine space utilization 
within various types of files: 

□ "Peering Inside the PE: A Tour of the Win32 Portable Executable File Format", Matt Pietrek, 
March 1994 

□ "BIvIP Fonnat: Windows Bitmap File Format Specifications", Wim Wouters, May 2000 

□ Appnote.txt from tiie PKZip Website 

□ The ISO-ITU JPEG standard in a file called itu- 1 1 50 .ps 

□ CRYX's note about the JPEG decoding algorithm. Copyright 1999 Cristi Cuturicu. 

□ Inside Windows Cabinet Files by Sven B. Schreiber 

Using this r^earch data, and proprietary data collected manually by 
examining many available file types, the present invention embodies a set of 
programmatic rules that represent techniques for placing data within all the known 
safe locations (see FIG. 6, step 27) to store protected (interleaved and/or multiplexed 
and/or encrypted) data in all tested file types, and once hidden, the present invention 
provides a similar inverse set of capabilities (see FIG. 7) that provide mechanisms to 
find the hidden information (see steps 33 34 35), extract it (see steps 36 37 38 39) 
and provide the decrypted, de-interleaved data to the requestor at step 40 of FIG. 7. 

The following code example illustrates an embodiment of the invention 
described above and the programmatic rules illustrated above and with reference to 
FIG. 6. Each type of file (for instance text files, jpeg photographs, GIF web images, 
executable "exe" or PE files, any and all types of files known to the operating 
system), have specific rules within this invention associated with them. The code 
example below shows the logic used to determine the available fi-ee space within a 
given file. One of the parameters is a call-back process (writeMapLocation) which 
creates a list of available locations in the form of a map stmcture (sometimes called a 
"raw" map). The second parameter is the current MapRawList to which the 
informative hst is to be written. The method used to determine the byte locations to 
pass to writeMapLocation varies for each file type (BMP, EXE, etc). 

CBMPFile::GetMapLocations( 

void {*writeMapLocation) (unsigned long,unsigned long, bool, boot, 
bool, MapRawListJ 

MapRawListJ **rawMapTail 

) 
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{ 

unsigned long i; 

unsigned long pos = startLocation + STARTOFPALETTE + 
(PALETTE.ENTRY.SIZE - 1); 

for (i=0;i<paletteEntries;i++) 

{ * 

(*writeMapLocation) (pos, 1, false, true, true, rawMapTail); 
pos += PALETTE_ENTRY_SIZE; 



10 } 



15 // 

// FUNCTION: WriteMapLocalions(unsigned long offset, unsigned long length) 
// 

// PURPOSE: Added the given locations to the RawMapList 

// 

20 // COMI\/IENTS: 

// 
// 

void WriteMapLocations( 
unsigned long offset, 
25 unsigned long length, 

boo! isNonZero, 
boo! isAlwaysFindable, 
bool islnsldePiie, 
MapRawList_t ** rawMapTail 



30 ) 
{ 



BYTE flags = 0; 



if (length == 0) 
35 return; 

if (isNonZero) 

flags 1= ISNONZEROFLAG; 
if (IsAlwaysFindable) 
40 flags |= iSALWAYSFINDABLEFLAG; 

if(islnsideFile) 

flags 1= ISINSIDEFILEFLAG; 

(*rawMapTail)->offset = offset; 
45 (VawMapTail)->length = length; 

(*rawMapTail)->flags = flags; 

(*rawMapTail)->linlc = (MapRawListJ *) malloc (sizeof(IVIapRawList_t)); 

*rawI\/lapTail = (*rawMapTail)->llnk; 
50 lnitlVlapRawEntry(*rawMapTail); 
} 



55 
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In another embodiment of this invention illustrated in FIG. 9, content is 
placed in various locations and Hhen protected using a technique referred to as 
translocation, a process that is described in further detail below. Prior to discussing 
the concept of translocation, it is necessary to first describe the nature of such 
locations for the placement of such information. Such information may be executable 
content sudhi as a Windows program, for example notepad.exe, or may take llie form 
of other content, for example, a text file, a movie, or an audio file or music. The file 
system consists of storage space on one or more devices and a table of contents or 
directory that provides locations and offeets. There are multiple embodiments of this 
invention with alternate strategies for placement which maybe used individually or 
in combination. Note that content maybe placed as follows in whole or in part, since 
hiding even part of complex content may render the remainder useless, such that the 
first 25% of a given content type can be hidden and the remainder is made secure by 
the lack of the hidden part, even thou^ the remainder is accessible. 

In one such implementation, content may be placed within the file system 65 
but hidden beUveen the files 56 in space, for example, that is created by the 
fragmentation of predetermined storage blocks on the storage media such that the 
files visible in the file system do not entirely occupy the space allocated for them. 
Such content is placed in unused between-file fragmentation space within the 
bounds of the file system 56 such that its location is unknown to the table of contents 
54 so that no file system access at the file level will be able to locate or access the 
files. This type of information hiding may require the information be subdivided into 
small parts and hidden in multiple smaller locations, since the available space 
between files may be fragmented. 

hi another embodiment 66 such content maybe placed outside the file system 
entirely 59. hi this implementation, the amount of contiguous available space is 
larger and flius such a file may be placed in contiguous locations, however note that 
such a file may in fact still be subdivided and placed into multiple disordered 
discontiguous locations for added security even in the abundant contiguous space in 
such Kcfra-file system 59 locations. 
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In an alternative embodiment 67, the content is placed partly between the 
files within the file system 62, and partly in space outside the file system, namely the 
extra-file system 63. 

The concept of translocation as implemented in this invention and as 
illustrated in FIG, 9 is described with reference to examples 65, 66 and 67. 
Assuming that the apparent target is a hacker's tool such as "ProcDump.exe" and the 
translocation replacement is a stub executable whose sole instruction is to exit, any 
attempts to execute this hacker's tool, such as by double-clicking on it with a mouse, 
would result in the execution instead of the stub, which would immediately exit, such 
that the execution of ProcDump would appear to have failed to an outside observer 
with no apparent reason why. The actual mechanisms by w^hich this process operates 
are as follows. The protected content is copied firom its former location 55 to a new 
location 56; it maybe optionally encrypted during the copy process if desired. In the 
present example this location is actually a series of noncontiguous smaller locations 
that the content is subdivided into, between files of the file system in the space 
created when file system blocks are fi'agmented due to partial usage. These blocks, 
when used, are marked in the file system's records so they will not be inadvertently 
overwritten or re-used, but they do not have a corresponding entry in the directory 
system so they are not accessible fi-om the standard file system interfaces. The 
former location 55 is populated with a file whose attributes are identical with the 
protected content in tenns of name, size, extemal appearance, but whose behavior or 
contents differ as desired (in the above example, ProcDump is replaced with a stub 
that exits). Attempts to execute "ProcDump" are made but they access the former 
known location 55. The translocation system can at any time retrieve the actual 
contents from the new location 56 and either repopulate them into the former 
location 55 or provide them as needed to the other components of the present 
invention. 

Similarly in examples 66 and 67, the locations that are populated with the 
translocated content (in this case the real "ProcDump.exe" we're hiding) are either 
outside the file system entirely 66, or, in tlie case of example 67, partly within the 
fi-agnfented between-file space and partly outside the file system. 
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Note that in an alternate inverse embodiment of this invention, the original 
file is not moved at all 55 but rather the translocation replacement file is placed into 
the new location 56, and the file system's pointers 57 are temporarily updated to 
point to the translocated replacement file. Note that locations outside the bounds of 
5 the file system, for example location 59, maybe on the same media as the file system 

or on entirely different media . for example, random access memory, rewriteable 
storage, network storage, or any other viable storage medium accessible to the 
system. 

An example process used to create a translocation replacement file is now 

1 0 detailed with reference to FIG. 1 0. For continuity the example above is referred to, 

where the original file is "FrocDump.exe" and the translocation replacement is 
"stub.exe" which does nothing other than exit (of course any file of any type may be 
replaced by any other file of the same or different type, as desired) 75. The 
ProcDump file is first scanned and its attributes recorded; any icons or other 

15 resources are copied and duplicated 68. The ProcDump file is copied at step 69 to 

various predetemiined storage locations, for example locations 56, 69, 62, and 63 of 
FIG. 9. Optionally to ensure added security, the original contents of ProcDump are 
zero-filled 70 and deleted in entirety 71 fi-om the media, while bypassing the file 
system so that the directory entry and pointers remain intact. The original location is 

20 used as the location and bounds for the translocation container 72, and this container 

is then populated with the icons 73 and other attributes 74 of the original 
"FrocDump.exe", and the container is then populated with the logic and contents of 
"stub.exe". Thus any attempt by an unauthorized individual to execute 
'TrocDump.exe" results instead in the execution of "stub.exe*', and this persists even 

25 if the file known as "ProcDump.exe" is copied elsewhere, since the content has been 

replaced at a physical level. 

With reference to FIG. 11, in certain embodiments, there may arise 
circumstances where an authorized entity has a valid need to access content which 
had previously been translocated as above. Operating system interfaces for file 

30 access can in this case be monitored, and attempts by an authorized entity to access 

the translocation container 76 result m retrieval of the original target 77 from storage 
locations. If encrypted as part of the storage process, decryption is performed on the 
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content 78. An execution environment appropriate to the content type 79 is invoked 
on behalf of the requesting entity (for example, if the protected content were 
"readme.txt", a text file, the application "notepad.exe" might be launched). The 
retrieved content "readme.txt" is then provided to the execution environment 80, and 
the requesting entity's needs are met ubiquitously. 

As explained above, translocation is defined as the ability to pro\dde 
ubiquitous redirection, which may be used for both the hiding of information, and for 
the purpose of defending against attacks by disabling the opponent's access to the 
necessary reverse engineering tools. Translocation may be embodied in a system that 
actually moves content, or in a system that redirects access to content without 
moving it. For example, in the case of moving content, an individual's intent on 
reverse engmeering a protected system may wish to run the Visual C++ development 
tools to attempt to debug the running system. When the protective system is invoked, 
among the first things it does is translocate all threatenmg tools it finds, such that 
Visual C++ is moved fi-om its old location 55 to a new location 56 (see FIG. 9), and 
the contents of location 55 are replaced with an executable that does nothing but exit 
when run. Thus when an attempt is made to run the executable file for Visual C++, 
the file that is actually run is this stub executable that does nothing useful. 

An example of translocation that redirects without moving content is similar. 
With reference to FIG. 23, such a mechanism employs a connection to the operating 
system interfaces 137 for, in this case, file access, and when an attempt is made to 
run Visual C++ at location 55 (see FIG. 9), the call is monitored and intercepted at 
steps 138, 139, and the executable file that is actually run 140 is the replacement stub 
file 56. This replacement stub file can do far more than just exit; an example is an 
embodiment of this invention in which the replacement file is a crippled version of 
the desired target file 55. In order to further obscure what is happening, care is taken 
in this example that when the replacement or redirected file is invoked ( for example 
FIG. 11 ) to. touch 141 the desired file 55 so that any file system monitoring tools 
that may be running will see the expected access 55. Note that as in examples 66 and 
67 of FIG. 9 there are embodiments of this invention in which the redirected or 
moved content resides wholly or partly outside the file system 59, 62, 63, and 
embodiments in which the redirected or moved file does not reside in contiguous 
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locations but rather in two or more subdivided locations 62, 63. In one such 
embodiment, the translocated content is stored in the fashion that an M-bit 
watermark 12 is stored 31, across multiple M-bit locations with no regard for 
contiguity, and later accessed by means of the methods described above in 
association with JIG. 7. 

Note that translocated content leaves no obvious clues; the process used to 
create 73 these substitute or redirected files as in the example FIG. 10 insure that the 
replacements have all the proper attributes, through steps 68 and 74, including all 
icons, size and date attributes, and all other properties of the original. Also note that 
the above example was related to an executable program file, but there are other 
embodiments of this invention. In one such embodiment, the content is audio, and 
when invoked in the process of FIG. 11, the act of execution causes fixe concurrent 
invocation 76 of an appropriate audio player/helpa: application 79. In another 
embodiment of this invention, the content type is a digital video stream, a popular 
movie title. In this case, the execution environment 79, when invoked 76, is a digital 
video player helper application. All digital content types are therefore supported by 
this aspect of the invention. 

Another embodiment of this invention as exemplified in FIGs. 12, 13, 14, 15, 
and 16. This embodiment relates to a set of mechanisms that operate to tokenize and 
obfuscate (see step 83 of FIG. 12, reference 88 of FIG. 13 and step 92 of FIG. 14) 
content of all types (see step 98 of FIG. 16, below) in order to eliminate trivial 
observational analysis, and in the case of executable content, to greatly increase the 
difficulty of unaufliorized debugging. This embodiment also serves to prohibit the 
modification of all types of content, since the tokenized obfuscated content 89 cannot 
be modified using standard editing/modification methods due to its proprietary 
tokenized formatting. In the case of executable content, disassembly is also 
prohibited by this process since the resultant output 84, 89 is no longer standard 
assembly language. 

For example, with reference to FIG. 12, digital content 82 maybe tokenized 
according to any of a number of standard tokenization mechanisms 83, and the 
resulting tokenized content 84 is stored (see FIG 13, step 89). With reference to FIG. 
1 5, the stored tokenized content 93 can be later be retrieved and subsequently 
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reconstituted and executed 94, provided an execution output 95 that is the same as 
that which is ori^ally intended 

With reference to FIG. 13, the stream of digital content to be tokenized and 
obfuscated 82 (see FIG. 12) is presented. The digital content is read and its type is 
determined 86. The system and method of the present invention preferably 
recognizes all existent digital content/file/stream types; in the case of this example 
the file type is determined to be an executable or Windows "PE" file conformant 
with the specifications found in "Peering Inside the PE: A Tour of the Win32 
Portable Executable File Format", Matt Pietrek, March 1994. The content is parsed 
87, with a lexical parser similar to those found in many compiler fi-ont-end 
mechanisms. Portions of the content are replaced with tokens 88 that bear an 
appropriate lexical relationship 91, understood to the mechanisms of this invention, 
to the content and the context. In one example the token replacement may be fixed; 
for example the assembly language MUL or multiply operator is replaced with the 
token ^, To fiirther complicate this example, the token replacement maybe variable, 
for example based on location, such that the MUL operator's token is ^ if it occurs in 
the first 50 lines of assembly code, otherwise it is #. 

Details related to the substitution of tokens are provided at FIG. 14. The 
content is parsed at step 90, as described above in FIG. 13, step 87. Lexical 
boundaries of the parsed content are identified 91, and the replacement is performed. 
In other words, using the English language as an example, if one were tokenizing the 
sentence "My dog does not understand my dogma." it mi^t be appropriate to replace 
the tenn "dog" with the token but it would be wrong if we also made the same 
replacement within the word "dogma" and turned it into "*ma" because the context 
and lexical meaning of "dog" and "dogma" are different despite the fact that the first 
three characters are identical. A context fi-ee search would find them to be the same; 
"dog" matches "dog" and matches the first three characters of "dogma" but since the 
meaning is different, the system must be intelligenf enough to do more than match 
the appearance of an item; the item's meaning and contextual relationship must be 
understood. Thus it is not a simple context free blind replacement such as doing a 
global replace edit using Microsoft Word; the location and meaning of each item. 



wo 03/029939 



PCTAJSOl/44045 



"41- 

and its relationship to items before and after it are all relevant to the substitution 
logic used to tokenize it 

Returning to FIG. 13, the tokenized content is written out 89, and may then 
be interleaved, multiplexed, encrypted, and/or hidden as illustrated in the previous 
examples described above. 

With reference to FIGs. 15 and 16, at a later time, as needed, when it is time 
to execute this content, the tokenized content 93 is located and extracted at step 97 (if 
it was indeed interleaved, multiplexed, encrypted, and/or hidden as described above). 
The content type is determined at step 98, and the tokens are parsed and converted 
back into standard executable code 99. The content may then be re-obfuscated 100 
by applying known variations on standard assembly language which serve to confuse 
debugging and disassembly tools. It may then be executed in an appropriate 
execution context 101; in the case of executable *TE" program code, that context is 
the operating system itself to be executed 102 upon the processor 5 (see FIG. 1). 

In the example below, this invention replaces standard assembly language 
elements with permuted assembly language which has attributes that cause 
disassembly utilities such as, for example, the popular disassembly tool IDA Pro, 
sold and distributed by the Belgian firm DataRescue. Such tools depend on 
assembly language being formed and structured in specific standard ways; the 
enhanced assembly language generated by this invention offers the same logical 
function as the code it replaces but is resistant to disassembly as shown in the 
example code illustrations below. 

The first such code example below illustrates this invention's insertion of jmp 
statements to instances of the following assembly language instructions: inc, dec, 
call, jmp, and push 

Convert this: 0000: 90 nop 0001 :FF inc 

To this: 0000: EB FF jmp 0001 0002: inc 

For example, this embodiment changes instances of "jumps" to (push and 
return) calls: 

Convert this: stmt; JUI^P2V(addrjmp) "\tjmp\t%0\n" 3 
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To this: stmt; JUMPV(adcirjmp) •\tpushl\t$%0\n\tret\n" 3 

For example, jumping into the middle of an instruction to confuse all 
disassemblers: 

erp: mov ax,0FE05h 
jmp $-2h 
add ah.OSBh 

Another code example of the same class of techniques used by this invention: 



mov 


ax.OFEOSh 


; ax=FE05h 


jmp 


$-2 


; jmp into '05 FE' 


add 


ax.OEBFEh 


; 05 is 'add ax' 


cid 




; a dummy instruction 


add 


ah,3Bh 


; ax=2503h 



Note that the "add ah,03Bh" command is instantiated to insert the value 
2503h into location ax. By adding five bytes (as opposed to simply using teov 
ax,2503h') this code will defeat all known disassemblers. Even if the instructions are 
disassembled properly, the value of ax will not be known, so every int call after this 
point will not be commented properly, as long as the system never moves a value 
into ax. This embodunent of the invention can conceal the value from the 
disassembler by using *add ax' or 'sub ax' whenever possible. Thus any value can be 
put into ax. 

This invention, of course, must make such substitutions in an automated 
fashion; the code example below illustrates such programmatic assembly language 
substitution: 

/* Output tine anti-disassembly code */ 
r Based on the following code 
printrmov ax,0FF05h\n"); 
printhmp short $-2h\n"); 
printC'mov ax,OFFFFh\n"); 
printhmp short $-07eh\n"); 
*/ 

unsigned char randomBytes[10]; 

inti; 

char buf[100]; 

for (i=0;i<4;H-+) { 

randomBytes[i] = rand{) % 256; 

} 
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sprintf{buf, '^t.byte 0x66. 0xb8. 0x05, 0x%.2x\n". 
randomBytesIO]); /*mov*/ 
print(buf); 

sprintf(buf, '^t.byte Oxeb, OxfcVi"); I* jmp */ 
print(buf); 

sprintf(buf, "\t.byte 0x66. Oxb8, 0x%.2x, 0x%.2x\n". 
randomBytesIl], random Byte5[2]); /* mov */ 
print{buf); 

sprintf{buf, "\t.byte Oxeb, 0x%.2x\n", 
randomBytes[3]); /* jmp */ 
print{buf); 

} 

emitcodeO; 

In an alternative embodiment of the above aspect of the invention, and a 
variant example, the inventive system and method, after having tokenized and 
obfuscated the content and optionally interleaved, multiplexed, encrypted, and/or 
hidden it, later, as needed, when it is trnie to execute this content, the content is 
located and extracted (if it was indeed interleaved, multiplexed, encrypted, and/or 
hidden), parsed, content type determined, the tokens are parsed and execution occurs 
in lockstep with the conversion to executable content so the reconstituted content is 
never written to a file or provided to any entity in the system, but is rather executed 
on the fly within a custom execution context 101 (see FIG. 16) or custom interpreter 
101. Note that "conteaf maybe any digital content; executable program code, audio, 
video, digital documents, and the "execution content" is constructed to execute the 
content The meaning of "execute" varies depending on the content; for example 
audio or video would be executed on an appropriate audio or video player, 
documents presented in an appropriate viewer, appUcation programs and games run. 

An embodiment of this invention may generate for example instances of the 
variant assembly language as illustrated in tiie example above, and thereby be 
resistant to disassembly, and may also be made more difficult to debug by defeating 
automatic disassembly tools using obfuscated assembly language programming 
techniques, for example inappropriate not-used jumps into the middle of instructions. 
Such obfiiscation, or similarly effective methods accomplished by other means, 
enhanbe the security of the invention. Note that this is in addition to the inherent 
security of running within an interpretive environment. The interpreter operates as a 
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shield from debugging and reverse-engineermg tools. The interpreter serves as a 
layer of abstraction between the protective invention and the real operating system. 
The values found in system memory and registers will not be directly related to the 
logical flow of the interpreted program; they will show the debug state of the 
interpreter itself instead, and that will make assembly language debugging very 
difficult. 

In another embodiment of this invention described with reference to FIG. 17 
and FIG 18, a protective system for digital content, or any running software 
application or system of any kind on any platform, is. itself protected from being 
debugged, monitored, logged and understood by an invention mechanism which 
creates careftilly targeted and tuned system activity, or "saturation" activity. This 
activity causes an instrumented or debug-enabled computer system to generate large 
volumes of debug, log, and/or monitor-tool trafiSc unrelated to .the protective logic. 
For example such traffic can make a log that would have been 1 5 kilobytes grow to 
be 1 50 megabytes. Monitoring/logging/data watching debug techniques are easily 
overwhehned by this approach. One example of such a logging monitoring tool and 
it's usage is Filemon, an excellent freeware tool which logs system file activity. 
When exposed to the saturation traffic 110, the Filemon event log can grow to be 
orders of magnitude larger than it would otherwise be. Events of interest to one 
debugging or reverse engineering the system are therefore lost in the process. 

This targeted saturation embodiment of the present invention operates as 
follows. The protection by saturation of a system or application first depends on 
understanding the nature of the normal sj^tera traffic generated by that application. 
Therefore, with reference to FIG. 17, the protected entity must first be analyzed as in 
step 107. The protected entity is executed on a system that is running the saturation 
profiler tool 104. This tool profiles activity 104 in such ways that classes of activity 
are monitored (for example SCSI calls or registry calls or file opening) and statistics 
are gathered (for example, scsi calls logged during the execution of program material 
to be protected). For example, 400 file opens, 3500 reads of 2048 bytes each, 120 
query commands. All aspects of system utilization are monitored and logged and 
categorized by type and frequency. This forms a profile of activity for the program 
material. This profile is encoded in a fa^on readable by a later process of this 
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invention (FIG. 18, described later in this document), and written to a "saturation 
list", along with a tuning profile 105 with detailed encoded instructions 106. These 
instructions specify the desired traffic types and volumes, for example to mask the 
SCSI traffic, in one embodimait, the present invention is directed to generate 4000 
file opens in similar drive locations and sizes, 30,000 reads, 500 quay commands. 

As described in FIG. 18, the invention which actually generates the directed 
saturation traffic may first open the saturation jprofile 108, decode the instructions as 
required, determine which types of traffic axe desired (for example network traffic, or 
as in the example above SCSI traffic), coimnunicate with the appropriate saturation 
engine (as above, the scsi saturation en^ne would be used in this example; each such 
entity may be used indiNidually or in combination, such as for example doing both 
SCSI and network saturation) 109. The saturation engine then executes the required 
commands 110 and FIG. 19, (see below for details) and generates the appropriate 
levels of traffic. 

The functioning of an individual instance of a saturation engine 116 is shown 
in FIG. 19. The SCSI example firom above provides an illustration to one skilled m 
the art; the SCSI interfaces are utilized and an event driven mechanism is created, 
where the first logical step is to wait on the event of either a command completion or 
a new external request to issue a command 112. Upon awakening, if a command is 
pending (a SCSI file open, for example, as the next saturation command in the 
desired saturation list), it is executed 113, and synchronously waited upon if desired 
114 witti varying next-step results optionally defending on completion status. If 
normal completion, the process executes a hard sleep for a predefined interval if 
desned (to throttle back activity) 115, and then sleeps again waiting on the events as 
in 112. This is indeed a loop and would be infinite if the queue of commands were 
infinite, however being event driven, the loop suspends execution after the last 
command is consumed and is optionally swapped out, eliminating system resource 
utilization until again needed. The throttle-back sleep allows the saturation system to 
selectively control its utilization of system resources dynamically, for example to 
avoid monopolizing system resoxurces when they're needed for more unportant 
activities. The ability to be throttled back is controlled by the process of the invention 
as needed to reduce saturation traffic in specific ways at specific times, and may be 
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overridden programmatically by other invention embodiments within the protective 
system if they determine they need more resources for any reason. 

All individual saturation engines are controlled by a saturation scheduler as 
shown in FIG. 20. The scheduler opens, decodes, and reads (parses) 117 the 
saturation profile and system settings directions fi-om the saturation list previously 
described. The necessary saturation engines are polled, 118 launched if not already 
present, and the engine specific commands (for example SCSI commands as above) 
are queued to the saturation engine's 123 main scheduling loop. The underlying 
process driving the command queue mechanism is event driven and clock driven, 
with saturation engine tasks being fed commands at predetermined rates. The 
command feeder process is itself event driven, sleeping and waiting 119 upon the 
event of conunands entering the queue, issuing the command 120 with dynamically 
controllable command frequency and adding additional sleep time commands to the 
payload so the saturation en^e knows how much additional sleep over and above 
the event queue events is required (this is the throttling mechanism as described in 
the paragraphs above), and monitoring the effect on the system to detennine if the 
throttling amount and the command queue depth and speed are appropriate to the 
task. This main scheduling loop 123 would be infinite if not event driven, however 
since it is event driven (as the individual saturation engine loops are) when the queue 
of commands is empty, the system is quiescent, suspended, and optionally swapped 
out. Upon overall completion, the scheduler exits 123 and may optionally kill all the 
individual saturation engines previously spawned. 

In another embodiment of this invention as shown in FIG. 21, a filter, shim, 
device driver extension, or substitute device driver is inserted into system interfaces, 
interposing itself 125 between the original driver or interface and all other entities by 
stealing inputs directed towards those interfaces, reattaching any previously attached 
entities to the public "subsumed interfaces*', optionally passing through or modifying 
the traffic to those interfaces, optionally logging traffic, thus subsuming the **public 
face" of such interfaces. An example would be to take over the interface to the 
system '"beep" fiinction. Every time a system 'T^eep" (the annoying noise the PC 
speaker can make at power up on many Personal Computer systems) is requested, the 
shim steals the command. In this example, if the requesting process is your email 
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program, the beep is passed through, and the system beeps. If the requesting entity is 
a disallowed entity, Uke an equally annoying pop-up browser wkdow, the beep may 
be thrown away and thereby suppressed. Note the vdnerability of such an interface 
shimming techniques in its simplest form is tiiat another such "imposter" shim 
intended to compromise such a "protection" shim could be inserted after (or before, 
or both before AND after it, to allow it to be bypassed enturely at will, depending on 
the intent) the protection shim, thus obviating the utility of such a mechanism. In 
other words, the shim itself can be monitored or subvaled if it in turn is shimmed. 
Therefore this invention compensates for that vulnerability by continually 
reconnecting. The process as shown in FIG. 21 initiates by first finding the system 
interfaces it intends to subsume and uses the lowest possible level of interface; 
interfece use is performed based on that low level information rather than using 
higher level abstractions made available by tiie operating system. The interface's 
external interface functions are subsumed by the shim 125, any commands received 
while impersonatmg the interface are optionally either passed through, modified or 
discarded (the system may desire to do any of those things, for exaniple if 
authorizing by PID, a read access might be thrown away of the requesting PID were 
believed to be a security threat hke a debugger) 126. Alternatively, the system could 
transparently pass all requests through 126 and optionally offer an undocumented 
other interface so a knowing programmer could access system functions through the 
shim directly 126, bypassing system interfaces and associated interface monitoring 
tools. For example as part of a broad throttling process, the process may optionally 
sleep between subsumed-interface-commands 127 thereby retarding pubUc interface 
access, thus providing reduced system resource usage as desired to specific entities 
on the system as needed (for example to starve a reverse engineering tool and reduce 
its utility). Once a number of such commands have been processed and time intervals 
optionally slept by the process, it detaches fi-om the operating system interfeces and 
inmiediately reattaches 128 again at the lowest level; this to ensure that it has not 
been compromised by another shim inserting itself before or after it. This 
reattachment loop 129 may be infinite, the shim may be left in place indefinitely to 
exit upon system shutdown, and optionally not reconnect at next reboot, effectively 
thereafter disappearing from the system. 
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In the code example below, this dynamic-reconnection mechanism of the 
present invention manifests itself as a process that attaches to the first location 
directly at the interface level, and forces all subsequent shims of any other kind to 
attach themselves after the invention by continually reattaching in flie jSrst position: 



// find the bottom of the bottom of the OS-Interface ShimList; AutoReAttach is placed 

//at the top of the ShimList. If an authorized request Is received, we use the saved location of 

the //bottom of the OS-interface ShimList to bypass anyone who might be Attached in 

between „ 
//If an unauthorized request is received it is passed down the ShimList normally. 
//The Attach and reAttach logic keeps the _ Attach at the top of the ShimList. 



// install and remove a dummy System Interface Attach in order to get 
// the address of the last Attach in the OS-Interface ShimList 

sj)PrevAttachDummy = 

ANYlNTERFACEMgrJnstallSystemlnterfaceApiAttach(FnAttachDummy); 
ANYINTERFACEMgr_RemoveSystemlnterfaceApiAttach(FnAttachDummy); 



// Keep going until we get to the OS-interface itself 

apAttachs[0] = sjDPrevAttachDummy; 

widAttach = GetAttachId((BYTE *)*{apAttachs[0]), NULL); 

idxShimListDepth = 1; 

v^hlle (widAttach != ANYINTERFACEIVIGR^VXDJD) 

^ // Remove all of the Attachs we have found so far 
for (ii = 0; il< idxShimUstDepth; ii++) 

^ ANYINTERFACEMgr_RemoveSystemlnterfaceApiAttach(*(apAltachs[ii])); 
} ' 

// Add and remove a dummy Attach to get the pointer to 
// the next Attach in the ShimList 
s_pPrevAttachDummy = 
ANYiNTERFACEMgrJnstallSystemlnterfaceApiAttach(FnAttachDummy); 

ANYINTERFACEMgr_RemoveSystemlnterfaceApiAttach(FnAttachDummy); 
* apAttachs[idxShimListDepth] = sjPrevAttachDummv^ 

// Now replace all the Attachs we removed above 
for (ii = IdxShlmListDepth - 1; ii >= 0; ii-) 

^ ANYINTERFACEMgrJnstallSystemlnterfaceApiAttach(*(apAttachspi])); 
} 

// Get the ID of the most recently found Attach 

WidAttach = GetAttachld((BYTE *)*(apAttachs[idxShimListDepth]), NULL); 

// Increase the depth by one for the next pass 
idxShimListDepth++; 

} 

// Remember the address of the final OS-Interface "Attach" 
s j)AnylnterfaceAttach = s j)PrevAttachDummy; 
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// Install our Attach at the end of the ShimList 
if{s_dwSiDct== 0) 

^ s jPrevAttach = ANYINTERFACEMgrJnstallSystemlnterfaceApiAttach(RchwyAttach); 
} 

static void FixAnylnterfaceShimList( 
// 

// 
// 
) 

// Install and remove a dummy Systemlnterface Attach in order to get 
// the address of the last Attach in the OS-Interface ShimList 
s_pPrevAttachDummy = 
ANYINTERFACEMgrJnstallSystemlnterfaceApiAttach{FnAttachDummy); 
ANYINTERFACEMgr_RemoveSystemlnterfaceAplAttach(FnAttachDummy); 

// If we aren't the last Attach in the ShimList, remove our Attach and 
// then reinstall us to get us back at the end of the ShimList 
if (RchwyAttach 1= *sjDPrevAttachDummy) 

^ ANYINTERFACEMgr_RemoveSystemlnterfaceApiAttach(RchwyAttach); 
s_pPrevAttach=ANYINTERFACEMgrJnstallSystemlnterfaceApiAttach{RchwyAttach); 

} 

return; 

} // End FixAnylnterfaceShimLlst 



In another embodiment of this invention, described with reference to FIG. 22, 
such an attach and re-attach strategy is implemented for the purposes of feeding 
spurious or saturation trafiSc into an opponent reverse-engineering tool In other 
words, this invention may be used to isolate and defeat certain reverse engmeering 
tools. For example, if the tool FileMon (an excellent reverse engineering tool 
distributed by Syslnternals.com) were in use, it would effectively monitor all usage 
of ttie filesystem and record all access in detail. If it were desirable to hide access 
from such monitoring tools, one such invention use for example would be to isolate 
FileMon by attaching one shim before it, and one after it, and having each shim 
continually reattach itself If each such shim had a data connection to each other 
bypassing FileMon it would be trivial to shunt all traffic around FileMon, effectively 
causing it to record nothing. In more subtle usage examples, selected traffic could be 
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hidden from FileMon in this fashion, while spurious saturation traffic was directed 
through it. 

In this embodiment, as above, a filter, shim, device driver extension, or 
substitute device driver is inserted into system interfaces in this case, interposing 
itself at step 131 between the reverse engineering monitoring shim and the rest of the 
system, thus apparently subsuming the role of the operating system interface and 
providing false and misleading data 132 to the monitoring/reverse-engineering 
shim/tool. The vulnerability of all such iaterface shimming techniques in thdr 
simplest form is that another such shim intended to compromise such a shim could 
be inserted after (or before, or both, depending on the intent) this process at any time, 
thus obviating the utility of such a mechanism. Thus, this embodiment of the 
invention includes a re-attachment mechanism 134 which guarantees a specific 
attachment location, in this case directly before the opponrait reverse- 
engmeering/monitoring shim, as specified by the invention's user. This is 
accomplished by repeated automated re-insertions 135 into the interfece chain. Such 
reinsertions are done in a fashion that does not impede function by waiting a number 
of time units 133 between issued instructions. Thus tiiis embodiment of continual- 
interface-reattachment can eliminate the threat of device redirection and monitoring 
tools being used to subvert the system. 

hi another embodiment of tiie present invention, as illusti-ated in FIG. 23, 
ubiquitous redirection of operating system interface access is employed to prevent 
the execution oj^ or access to, content that is disallowed, or to redirect access to otiier 
content in a manner that is transparent to the accessing party or process. As above, 
this embodhnent of tiie invention connects to the appropriate operating system 
interfaces at step 137, executing the reconnection logic as needed as in FIG. 21 and 
the description above. Calls to the interface are monitored 138, and when 
appropriate, intercepted 139. For example, if a tool such as FileMon were discovered 
on the system at the time of the invocation of this embodiment, it would be logged as 
an "access to monitor" and when it was accessed 138, it would be noted, and access 
would be rednected from the FileMon operation to a different executable 140, in this 
example an executable that does nothing but exit. At tiie same time tiiis redirected 
executable was launched 140, tiie originally intended executable is touched 141, such 
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that any other monitoring tools would show the access. Thus the individual intent on 
reverse engineering would launch FileMon and it would exit immediately 142. The 
individual might use other tools and discover that FileMon did indeed launch (file 
system access to the original file will be logged as tiiough it was launched). 

The code example below illustrates the invention discussed above in 
conjunction with FIG. 23; a means of redirecting access 140, for example, fi-om one 
executable 138 to another 139 ubiquitously: 

// If the access is one that the system wishes to disallow 
// and redirect, and a stub exe has been loaded, 
// point it at the stub file instead 

if (((DW0RD){-1)!=sJdxStub) &&// stub loaded 

(IfPidMatch) && '/ choose to disallow this one 

(fIsExec)) // and it is a .exe 

{ 

ii = sJdxStub; 

} 



The code example below illustrates the invention discussed above in ' 
conjunction with FIG, 23; in this case the code example is the do-notiiing stub 
executable that replaces access to the disallowed executable(s). 



intAPIENTRYMain( 

// 

// 

II 

HINSTANCE rhinstance (unused)*/, 
HINSTANCE /* hPrevlnstance (unused)*/, 
LPSTR /* IpCmdLine (unused) */, 
int /* nCmdShow (unused) 7 

) 
{ 

// Do nothing 
return 0; 

} // End MainO 



In another ambodimait of the present invention, a protective entity is created; 
such entity operates as an independent protective agent and secures all protected 
content fi-om unauthorized access. As depicted in FIG. 24, this entity, referred to as 
an "assassin", may be programmed to have multiple functions. For example, the 
assassin upon initialization 144 first determines how many other assassins and other 
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protected entities are present 145. System authorization functions are utilized 146 as 
depicted in FIG. 25, FIG. 26 to establish the correct identity of all processes on the 
system at all times. The assassin scans the system for the presence and execution of 
threat-entity-instances, such as debug tools Uke ProcDump and FileMon and even 
developer tools like Microsoft's Visial C++ 147. It also uses the functions detailed 
below to track the process or thread e?dt of any other entity including other assassins 
148. Upon determining intrusion has occurred (debugger running, unauthorized exit 
of any other assassin protective entity, aiiy changes or modifications 149 made to 
code or system components in any way within the system by any unauthorized entity, 
presence of ICE or other debugger) an exit condition is set up in which this assassin, 
and other assassins, and other system components will exit 150 based on either 
noticing that another has indeed exited or by passing a signal event between 
components of the system. In some cases an exiting assassin will kill 150 other 
system entities as a means of accelerating overall system component exit 

In the code example below, a first embodiment of the assassin process 
determines the identity of another assassin process (this is a two-assassin example) 
and instances 146, and monitors them for exit conditions 148. Upon an exit 
condition, this embodiment attempts to kiU other assassin processes and then kills 
itself 150. 

// Wait for a target entity to exit 
static bool WaitAndDeleteinstance( 

// 

DWORD in_dwldentWaitProc1 , // 1 st proc to wait for 

DWORD in_dwldentWa!tProc2. // 2nd proc to wait for 

DWORD in_dwldentKillProc, // proc to kill if proc 1 exits 

char* inp_s2Fn, // instances to delete 

char* inpjszFnFk. // more instances to delete 

char* inp szFnDel // add'! instance to wait for (NULL for assassins) 

) 

^ HANDLE ahProc[2] = {NULL, NULL}; // handles to wait on 
DWORD dwRes;. // result from wait 

int ii; 

char szFnWait[MAX_PATH]; // instance to wait for 
char szFnDel[MAX_PATH]; // instance to delete 
bool frargetlnsOpenFailed= false; 
HANDLE hTargetlns; 
cha^ szlsDel[MAX_PATH]; 
char szTargetlns[MAX_PATH]; 
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strcpy{szTargetlns, inp^szFn); 
strcat(szTargetlns, "target.inf ); 
strcpy(szlsDel, inp_szFn); 
strcat(szl5Del, "targetEntity"); 

*/ 

// Open handle to the 1st proc. This will be the 2nd assassin entity 
ahProc[0] = OpenEntity(ENTITY_ALL>CCESS, 
FALSE, 

in_dwldentWaitProc1 ); 
if(NULL = ahProc[0]) 

^ // If vye can't open this entity handle, then something is definitely 
// wrong, so kill the redirected (target) entity if there is one 
if (0 1= in_dwldentKillProc) 

^ KlLL„ENTITY„FROMJDENT(in„dwidentKillProc); 
} 

// Delete the instances and return 
DelTree(inp_szFn); 
DelTree(inp_szFnFk); 
return false; 

} 



// If no other entity was specified, then the current entity must be one 
// of the assassin entities 
if (0 == in_dwldentWaitProc2) 

{ 

// Wait for the original entity 
WaltForSingleObject(ahProc[0], INFINITE); 

// Kill the (target) entity if there is one 
if (0 != ln_dwldentKillProc) 

KILL_ENTITY_FROMJDENT(in_dwldentKillProc); 

} 

CloseHandle(ahProc[0]); 

// Delete the instances 
DelTree(lnp_szFn); 

return true; 

} 



At this point, this embodiment has proven that two assassin process 
identifiers were specified. This means that the currently executing entity is the first 
assassin launched. The monitored identifiers will therefore be that of the second 
assassin entity and the application entity (target). This embodiment will wait for 
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either one to exit; and assumes the target entity will exit when it is finished, in which 
case the first assassin entity can clean \xp and itself exit. If, on the other hand, it is 
the assassm entity that exits, this means that someone or something (a debug process 
perhaps) has killed it, so the first assassm entity will attempt to terminate the target 
entity and then delete all the instances of other system entities that it can. 

ahProcIl] = OpenEn1ity(ENTITY_ALL_ACCESS, 
FALSE, 

in_dwldentWaitProc2); 

// If we opened handles to both entities, wait for one to exit 

if(NULL!=ahProct1l) 

{ 

dwRes = WaitForMultipleObjects{2, // # of objects to wait for 
ahProc, // bandies of objs for wait 

FALSE, // wait for any 1 obj 
INFINITE); // how long to wait 

// If the assassin entity exited, that's an error 
if (WAiT_OBJECT_0 == dwRes) 

^ // Kill the redirected (target) entity if there is one 
If (0 1= in_dwldentKillProc) 

^ KILL_ENTITY_FROMJDENT(in_dwldentKillProc); 

CloseHandle(ahProc[0]); 
aoseHandle(ahProcI1]); 
DelTree{inp_szFn); 
DelTree(inp_szFnFk); 

return false; 

} 

CloseHandle(ahProc[1]); 
ahProc[1] = NULL; 

} 

// Now only the assassin entity Is left, so if an additional instance was 
// specified, wait until we can delete it before proceeding 
if (NULL != inp_szFnDel) 
{ 

// Set up instancename 
strcpy(szFnWa'it, inp_szFn); 
strcat(sEFnWait, inp_szFnDel); 

// Wait a while 

for (ii = 0; ii<180;ii++) 

{ 

■■ Sleep(500); 

// Exit the wait if the assassin entity dies or the signal 
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// instance disappears (or we can delete it) 
if { (i.Checl^AssassinProcO) || 

{(-1) == GetlnstanceAttributes(szFnWait)) || 

(Deleteinstance(szFnWait)) ) 

•{ 

breal<; 

} 

} 

// Kill the instances in our list 

for (ii = 0; ii< INSTANCE_DEL_NUiV12; ii++) 

strcpy(szFnDel, inp_szFn); 
strcat(szFnDel, INSTANCE^DEL^LIST2[ii]); 
Deletelnstance(szFnDel); 

} 

// Check ifthe instance exists 

If ((-1) != GetlnstanceAltributes(szFnWait)) 

^ // Wait until either we delete the instance, or the assassin entity is 
// kiiied 

while (!Deletelnstance(szFnWait)) 

^ dwRes = WaitForSingleObject(ahProc[0]. 250); 
if {WAIT_OBJECT_0 = dwRes) 
{ 

break; 

} 



if (IfTargetlnsOpenFailed) 

hTargetlns = Createlnstance(szlsDel, 
GENERICJWRITE, 
0, 

NULL, 

OPEN_EXISTING. 
0, NULL); 

if (INVALIDENT_HANDLE_VALUE 1= hTargetlns) 

^ CloseHandle(hTargetlns); 
} 

else 

fTargetlnsOpenFailed = true; 

} 



// If the instance open failed at least once, try to delete it 
if (fTargetlnsOpenFailed) 

//Deletelnstance(szTargetlns); 

} 
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} 



if (INVALIDENT_HANDLE_VALUE 1= hTargetlns) 

^ CloseHandle(hTargetlns); 
hTargetlns = INVALIDENT_HANDLE_VALUE; 

} 

/ 

// If the assassin entity was killed, that's an error 
if (WAIT_OBJECT_0 == dwRes) 

^ il Kill the redirected (target) entity If there is one 
If (0 != in_dwldentKillProc) 

^ KI.LL_ENTITY_FROMJDENT(in_dwldentKillProc); 

CloseHandle(ahProc[01); 

DelTree(inp_szFn); 

DerTree{lnp_szFnFk); 

return false; 

} 

} 

} 

// Now this invention knows that the target is really done, so clean up and 
// exit 

CloseHandle(ahProc[0]); 
Derrree(inp_szFn); 
//DelTree(inp_szFnFk); 
// Success 
return true; 

} // End WaitAndDeletelnstanceQ 



In another embodiment of the present invention, a determination is made by 
the system as to whether any given process, thread, entity, or access 154 on/of the 
system is an authorized process or an unauthorized process with respect to access to 
any of the protected, encrypted, interleaved,or hidden components of the system. As 
illustrated in FIG. 25, FIG. 26 establishing such an authorization context and 
enforcing it involves a series of steps as outlined below. One simple way to illustrate 
this process is by representing the authorized versus unauthorized entities as "fiiend 
or foe", in the form of a list 1 56. A snapshot of all entities on the system is taken 
153 and such a list is estabhshed 155. Any entities aeated subsequently, such as ' 
descendant children/entities of the original list entries, are appropriately added to the 



wo 03/029939 PCT/USOl/44045 



-57- 



list 154. When an access occurs, the accessing entity is identified 158 and identity 
infonnation is compared with the list 159 to determine whether the accessing process 
is a ftiend or foe. Access, or denial of access, is issued accordingly 160. 

The code example below illustrates the above aspect of the invention as 
represented in FIG. 25, FIG. 26. In the first such example, the identity of an entity is 
added to the list, and the hst is maintained as entity searches reveal new additions: 



// 

static VOID OnCreateEntity( 
// 

DWORD EntityToken 

) 
{ 

IdentityJ entityldentity, 

IdentityJ Descendantldentityldentity = EntityToken " sJdentityObfuscator; 

int ii; 

entityldentity = (ldentityJ)OS_GetCurrentEntityHandle(); 

dprlntfC'Dsrt: OnCreateEntity *** Entity Ox%IX created process Ox%IX \n", 

entityldentity, Descendantldentityldentity); 
// If the entity is in the allowed Identity list add the Descendantldentity 
for (ii = 0; Ii < MAXJdentity; B++) 

^ tf (entityldentity == sJdentityTablepi]) 

^ // If this Identity is already in the Identity array do not add 

for (ii = 0: ii< MAXJdentity; ii++) 

^ // Found the Descendantldentity in the table 
if (sJdentityTablepi] = Descendantldentityldentity) 
{ 

break; 

} 

} 

// Exit outer loop if Descendantldentity is already in table 

if ((ii < MAXJdentity) && (sJdentityTablepi] = Descendantldentityldentity)) 

{ 

break; 

} 

// Add a Identity to the array... Any 0 entry will do... 
for (ii = 0; ii < MAXJdentity; ii++) 

^ If (sJdentityTablepi] ==0) 

^ sJdentityTablepi] = Descendantldentityldentity; 
break; 

} 

} 

'//if (MAXJdentity ==ii) 
//{ 
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// Break out of the outer loop 
break; 

} II End if entity is in table 

} // End loop looking for entity In table 
return; 

} // End OnCreateEntityO 



The next code example illustrates the above invention as represented in FIG. 
25, FIG. 26. In this second such example, the identity of an entity is removed from 
the list: 



static VOID OnDestroyEntity( 
DWORD EntilyToken 

) 

IdentityJ IdentityDescendantldentity; 
int ii: 



IdentityDescendantldentity = EntityToken sJdentityObfuscator; 
// Remove this Identity rf it is in the list 
for (ii = 0; ii < MAXJdentity; ii++) 

^ if (IdentityDescendantldentity == sJdentltyTable[ii]) 
{ 

sJdentityTable[ii]); 
sJdentityTablepi] = 0; 
break; 

} 

} 

return; 

} // End OnDestroyEntityO 



The code example below illustrates mechanisms utilized to verify the identity 
of an entity and make a decision as to allowing or disallowing access to the entity. 



//Verify the Identity... 

for (ii = 0; ii < MAX Identity; ii++) 

{ 

if (identity == sJdentityTablepO) 

^ //lf((sFunc==FN_OPEN )|1 
// (sFunc == FN_FILEATTRIB) ) 

//{ 

fldentityMatch = TRUE; 
: break; 
} 

} 
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In another embodiment of this invention, any or all of the above aspects of 
the invention as illustrated and described above are incorporated into an application, 
or set of applications, and associated documentation, which are engineered to provide 
the aforementioned capabilities to digital content creation professionals and other 
such users. In this manner, digital content that a user desires to protect is provided to 
an appropriate toolkit as input and the techniques detailed above are applied to the 
content. The user is not necessarily exposed to the inner operation of the above 
processes, nor of the applied inventive techniques. The output of sudi a toolkit is a 
protected digital content entity. All types of content are supported and are equally 
applicable to the principles on the inveution, including; audio, video, executable, 
images, text, documents, e-books, and all other digital content of all types on all 
platforms as described above. The user of this toolkit may choose to include or 
exclude any of the inventive components mentioned above as part of the 
configuration of the tool, but at no time is it necessary for the user to understand in 
any detail how each component works, or how the individual components of the 
systan mteract. 

In another embodiment, the invention is directed to methods that allow for the 
electronic delivery of digital content in a fashion that prohibits content modification 
and duplication by unauthorized persons. The mechanisms detailed herein enable, 
support and secure the delivery of all forms of electronic content software titles, 
audio, video, and text/graphic/e-book/e-presentation formats using both hard media 
and network content deliver}' models. 

In one aspect, the product's files are modified, both before an electronic 
download while the product stiU resides on the server (or before being copied to the 
server), and the application files are also modified in the product directory following 
installation on the customer computer. Hidden data is inserted into these product 
files, this hidden data incorporating among other identifying data a securely 
encrypted transaction ID, which may also be modified by a function based on 
information about the target system's component-specific configuration information. 
The hidden data may alternately or inclusively comprise a simple numaic index or 
may also have meaningfid content interleaved into itself, as described above in 
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connection with FIG B. The data may be of any length. These hidden data items are 
preferably ins^ed into secret locations within the product files prior to kitting, at the 
point of purchase. 

There are multiple authorization models supported by the present invention. 
One such model is an entirely local model where the digital content may be installed 
or used from locally read hard media. Another such model is a network model in 
which there is a series of network transactions. In the latter case, the foregoing may 
describe a "target Computing System or Device" (the client, in other words) and a 
"Remote Server" (the server). Note the server may in fact comprise multiple server 
machines, each performing a set of either unique or redundant functions. In general, 
by putting certain key logical components on the remote server they are insulated 
from bemg reverse engineered. A good example, detailed elsewhere, is the 
generation of a system ID based on the configuration of the target system or client. It 
is desired under some circumstances that this ID value be converted into a usable 
encryption/decryption key (either symmetric or asymmetric in function). Based on 
the security concerns just discussed, if this key generation algorithm were on the 
client system it might be possible to reverse engineer it and compromise it, and 
thereby compromise the system. By having it be remote on the server in some 
embodiments of the invention, it effectively becomes a "black box" whose output 
may of course be intercepted and examined under some circumstances, but whose 
inner workings cannot be exposed by debugging, disassembly or other compromise 
of the client system, thus rendering the invention more secure under these 
circumstances. This client-server utilization of distributed service functions is 
optimal when possible but may not always be appropriate, as in the case of a CD or 
other hard media installation or usage of digital content where there is no network 
connection. Finally, it is important not to view the network versus hard media models 
as binary opposites or mutually exclusive models, there exists a hybrid model where 
the installation or distribution and subsequent usage of the digital content is from 
hard media but certain steps of the authorization process require a network 
connection. This model is a good compromise whenever possible because it allows 
certain key algorithm elements to be remote and therefore not susceptible to being 
attacked by local debug means, and the usage of it requires that the content creator be 
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wiUing to make an active network connection of some kind (whether broadband, 
dial-up, or other) a requirement for usage of their content. This set of decisions is 
entirely a business model based decision, not one limited by technical means. This 
invention offers optimum flexibility for all such business decisions, local, remote, or 
hybrid. 

As illustrated in the flow diagram of FIG. 27, content is processed and 
prepared for distribution in the form of a download archive 1 62, in part using and 
combining any of the mechanisms illustrated above in connection with FIGs. 3 
through 26. Hie archive is stored, for example at a server, in preparation for a 
download by a remote user 163. For example, as shown in FIGs. 28 and 29 above, a 
software or firmware component or tool (embodying technology detailed in FIGs. 3 - 
8 above) is deployed to the computing device or system on which the user desires to 
install or use the desired content (hereinafter referred to the "Target System" or 
"Computmg Device") and is run. The execution of this tool causes the system's 
component makeup to be analyzed and examined, and a unique identifying value is 
generated that represents the examined totality of the system 164. Each of the 
system's components are examined 165 as desired and selected aspects of each 
component's properties are considered in producing a unique identifying value for 
the system 166. For example, as shown in FIG. 30, generation of the identifying 
value may represent a consideration of component properties information such as the 
manufectiirer, and/or the firmware revision, and/or the serial number, and/or other 
directiy measurable physical properties such as performance, or amount of memory 
or other storage, or other enumerable hardware features 173 that are aggregated 174 
(see FIG. 30) by means of afunction, as simple or complex as desired; they maybe 
summed, for example, or mapped to a complex mathematical function yielding a 
numeric value. TOs function may look up values in.tables or calculate them directly 
from the input values, or both. Once this value has been arrived at, it is processed 
175 into a final system ID value that is used by the system 166 (returning to FIG. 28) 
in subsequent activity. This vahie may be used as an element in the creation of a 
system-unique encyption key, and this key 167 then appUed to an encryption process 
in which the system ID infonnation is encrypted and interleaved with other 
validation information as shown in FIG. 3 above. 
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In the embodiments of the present invention that support network distribution 
of content, depending on the context of the usage of the embodiment, the System ID 
value may be transferred 168 eitherto a remote server, a locally executing runtime 
process, or a locally executing installation process, and further manipulated as shown 
in FIG. 3 1 as it is used in conjunction with the Transaction ID 176 and then 
interleaved and encrypted 177, for example according to the techniques described 
above witii reference to FIGs. 3 through 8. This information is hidden within the 
content 178 as part of the delivery and optionally any installation process. 

With reference to FIG. 29, the identifying data or watemark as created in 
FIG. 28 is inserted mto the archive of the desired digital content product. This occurs 
on a remote server, usually, but may also occur locally in an installation from CD or 
other hard media. Note that the remote case is inherently more secure but either case 
provides an archive with hidden identifying or watermark data which is hidden and 
inserted as described in FIG. 31 as in FIGs. 3 - 8. The identifying watermark data is 
encrypted and interleaved and hidden in the archive 169. "nie entire archive, either as 
one monolithic file or as a collection of smaller files (segmented for faster download 
performance, more reUable resumption of download, and other network performance 
and robustiiess concerns) is encrypted using a key that is made unique for the target 
computing device system 170 such that is can only be decrypted appropriately on tiie 
same system as it was packaged for, as that decryption process will begin with the 
determination of the system ID of the target as in FIG. 28. The archive is tiransferred 
to the target system 171; in the case of a network transaction it is transmitted from 
the remote server to the target system, while in tiie case of a local installation, the 
archived data is provided to tiie installation process immediately. The recipient of the 
encrypted archive must of course have the appropriate key with which to decrypt it, 
and tiie present invention offers Uvo strategies for providing tiiat key. The recipient 
process can syntiiesize its own decryption key as described in FIG. 28 step 167, or 
can be provided by tiie remote system or otiier local process after it consumes tiie 
identifying data as provided by FIG. 28 and itself converts it into an appropriate key. 

Retiiming to FIG. 27, tiie components of a digital content product are 
processed and packaged, for example tiie standard component contents of a hard 
media digital product, including executable ffles, documentation files, image files. 
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and audio files. A standard hard media product may be taken in entirety from a CD 
release and modified 162 into a more secure downloadable product 163. Some or all 
of the content may include hidden identifying data inserted into it as shown above 
with reference to FIG. 31. This hidden identifying data, may optionally contain 
serialized purchase information related to the individual purchaser at which the 
Target Computing device is instrumented (step 164 of FIG. 28) and then examined 
(step 165 of FIG. 28) and a system identifier is created (step 166 of FIG. 28) by 
examining selected elements of the Target Computing device are identified uniquely 
and transformed into a unique identifying watermark for later use (steps 1 73-175 of 
HG. 30). 

Referring to FIG. 38, these watermarks or hidden data items may be created ( 
the concepts described above in FIGs. 3 throng 8 above can also be referred for 
mechanisms used in the creation, hidmg, and later extraction of these data items) 
may be created using multiple virtual streams as described above, in which, in this 
example, one such stream 209 represents System ID information contaming unique 
identifying information pertaining to the system, and another such stream contains 
transaction specific 210 (for example identifiably serialized) information generated 
by the server at the time of first authentication or download. These streams are 
interleaved and encrypted 211 (as shown above in FIG. 3). This concept can be used 
in an Electronic or Network distribution model, and may also be used in a hard media 
distribution model if the model allows for the Target Computing Device to be at least 
temporarily connected to a network. 

A mechanism of the invention authorizes the execution of product 
components (also referred to as Content) by providing a service that correlates 
attributes of the executable product with the system that is the target of the execution 
of the product. This applies to hard media and to Electronic Software Distribution 
(ESD). In this aspect of the present invention, the ESD content delivery phase may 
be authenticated by means of purchase (or other) unique transaction-specific 
information and/or system specific information. On a server that deploys this 
protected content, kit components are packaged as large archives or stored as raw 
data (in the same form as a hard media kit, including optionaUy, directory structures) 
and then manufactured on-demand, per-user, per purdiase. The final kit is packaged 
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as a collection of encrypted archives, or as a single monolithic archive, securely 
encrypted, and made usable or instaUable at the appropriate time by a secure product 
execution process. This process employs many of the techniques detailed above with 
reference to FIGs. 3 - 26, and is fiirther strengthened by the client-server 
authentication process detailed in FIG. 32. In this process, a component capable of 
determining the unique identifying data is deployed to the Target Computing device. 
The deployed component finds hidden locations ( as in FIGs. 3 through 8 above) 
within the content or elsewhere on the computing device 179. Once the identifying 
data is exti-acted, it is sent \'ia network connection to the server 1 80 where it is, 
turning to FIG. 33, received 182, de-interleaved and decrypted 1 83 (also as in parent 
ffling ¥IG. 3 through FIG. 8), and its authenticity is verified 184 against a database of 
known authorized content delivery tiransactions. Both the transaction ID and the 
system ID are verified 184, and an appropriate response is generated, containing 
critical content data that is interleaved and encrypted 185 (according to the 
techniques described above with reference to FIGs. 3 - 8) and then sent to the Target 
Computing Device 1 86. Returning to FIG. 32 the response is read fi:om the server 
181, the response being a necessary component to allow for the successM execution 
of tiie protected content on the Target Computing Device as discussed in the 
foregoing. 

la the network installation case, installation or re-installation may be 
disallowed at any time by the process illustrated m FIG. 33, in tiiat the server can 
make authentication decisions based on certain criteria in addition to the overall 
vaUdity of the system ID and tiransaction ID information, for instance total number of 
authentications or re-authentications, or the firequency of these events, or other 
information, can cause the server to dioose not to authenticate in the verification step 
1 84, such that the response data provided can indicate a system decision to generate a 
Boolean (i.e. "yes" or "no") state of failure, and/or can contain executable code 
insti^ctions interleaved with other data (as in parent filing FIG. 3 through FIG. 8) 
which, when ti-ansmitted at step 186, will cause the recipient process on the Target 
Computing device to exit, or to incorrectiy decrypt the content and then exit upon a 
failed content execution sequence. These server based authentication decisions are 
also influenced by subsequent transactions in which the user perforais a customer 
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service re-authentication either hy phone (verbaUy) or via the network. Such remote 
authentication/re-authentication invention methods may be executed within hard 

media based products as well. 

A mechanism of the invention processes product files in order to make room 
for larger quantities of hidden data. These additional spaces forbidden data item are 
integrated directly into any desired product files and are optionally pre-filled with 
filler content that matches the surrounding data to render them difficult to locate. 
This process modifies each desired product or content file as follows with reference 
to FIG. 34. Each desired file is opened and its filesystem allocation is increased by 
some amount 1 87. mtemal structure (as required per filetype) and allocation pointers 
are modified to match the increased allocation 188. File contents may be moved 
within the file as needed 189 as well. All of this available space may optionally be 
mapped 1 90, the map hidden, and then later used by another process as described 
above with reference to FIGs. 4 - 8. 

The process of the present invention may optionally segment the contents of 
the download kit such that specific small and critical files or even portions of such 
files are segregated from the main kit. The downloaded installation kit is therefore 
mcomplete in small but critical ways. The installation process requires subsequent 
authenticated recomiections to the download host, followed by small and volatile 
downloads of these critical items. Further this mechanism segments the contents of 
the installed digital product such that specific critical files and/or portions of such 
files are segregated and encrypted in a feshion that makes the installed product 
fiinction properly only on the intended target system. Further, the process of this 
invention may intentionally leave incomplete certain chosen program elements, the 
elements to be completed by means of executable information extracted from an 
authorization process, in some cases by hiding the information within the 
authentication response. For example the authorization process can provide the 
system with both nuiherical encrypted information (keys for fiirther system 
decryption use) and executable content critical to task completion. ]n one option, 
content may have certain sections altered such that key elements are removed and 
hidden elsewhere in seaet locations, for example on the media itself in the case of 
hard media, on the network in other cases, on other system storage devices in the 
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case for a component already instaUed on a computer system. Execution requires that 
these hidden elements are found and replaced in their original locations within the 
content. These elements are stored in locations that would not be copied easUy with 
either the installer media or the installed product directory. 

In a detaUed view of such a process, as in FIG. 35, alist of files requiring 
protection is assembled 191 and each file in turn is processed 1 92 in that the contents 
are parsed and certain sections (such as starting point, duration) are identified as 
critical either by manual selection, or by a file-type and context-aware algorithm 
(such as aparser or compiler front-end modified for this task), or by a simpler 
method such as for example by choosing every Nth section M bytes long. Each 
section is copied to an archive and stored 195 (where it is optionally interleaved and 
encrypted as described above). Each such section can be identified on an optional 
map (as per HGs. 4-8 above) 193, and then overwritten with data that is not 
properly fimctional 194; for example if the selected file is an executable file, the 
section may be overwritten with assembly language fliat exits or that runs in an 
infinite loop or that causes a severe processing error when run. Upon later use of this 
protected content, these missing sections must be filled in with the original data. 

Witii reference to FIG. 36, the authentication process for this concept in 
circumstances that allow the use of a network connection and remote server or 
servers to assist in the authentication, as each such damaged or modified or 
incomplete file is read, either as part of a stagmg process or during the runtime 
process of the digital content product, access to the specific section of the protected 
file is redirected through the translocation process as described above with reference 
to FIGs. 9 - 1 1 and valid data is substitiated for the filler data found in those 
respective locations. As each such location is accessed or "touched" (this location's 
filler nature is determined by means of eittier a Map file as described above, or 
directiy by algorittmiic means), the access is blocked in a synchronous manner 196. 
The blocking protective entity provides a remote server with a system ID 1 97, using 
the methods described in FIGs 29 and 30, or extracts the hidden system ID using the 
methods described in FIGs. 3 - 8, and a request for the missing data item. The 
remote system or server receives the request and validates the authenticity of the 
request as described above with reference to FIG. 33, where a valid Transaction ID 
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and a valid System ID are required, and where there may be additional requirements 
(i.e., number of authentications or re-authentications attempted, frequency, expiry of 
terms, etc) applied to the generation of the response data. The response data is 
generated on the server and provided back to the authentication process on the Target 
Computing System, where it is de-interleaved and decrypted 198 (as in FIGs. 3 - 
FIG. 8). This response data may contain Boolean flag data indicating the success or 
failure state of the authentication, and if the authentication fails, the consumption of 
this protected content can be caused to abort, either immediately, or in a deferred, 
indirect fashion (see discussion of exit-related processes as disclosed above with 
reference to FIG. 24, and in FIGs. 44 - 49 below). In addition to such direct methods 
of communicating a failed authentication within the response data, this process also 
supports more robust methods for example using the interleaved streams of the 
response data fomat to transmit the missmg, archived content. One mechanism is tiie 
inclusion within the response data of executable data (not from the archive but ratiier 
as response to a failed authentication) which causes an exit, an error condition, or 
which causes communication to another system entity which itself begins a 

cascading exit process. 

The authentication process on the Target Computer System next optionally 
de-interleaves and decrypts the response data (according to the processes of FIGs. 3 - 
8, above) and optionally uses the map data 199 to confirm placement of tiie data and 
to optionally determine the next location(s) to block on for subsequent reads. The 
authorization process then substitutes the filler data (as in FIG. 35 194) with the 
executable data 200. This may be done as a one-time fix-up of data during an 
execution, or may optionally be immediately overwritten after use with more filler 
data, by means of an event driven synchronized process, such that the corrected data 
is provided in a volatile, just-in-time fashion for a brief window of time. Access to 
the data item is then permitted by the system 201. 

This invention can also be embodied within a variation of the mechanism 
described above. With reference to FIG. 37, authentication can also performed 
locally without benefit of a network connection to a server or remote autiienticating 
entity. There are similarities to the logical flow of FIG. 36 above. When a read 
occurs and the target is one of the files that had previously been processed as in FIG. 
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35 above, and a location within that file is touched (this location's filler nature is 
determined bymeans of eitheraMap file 204 as described above in FIGs. 3 - 8, or 

directly by algorithmic means) that had previously been copied to an archive 1 92 and 
replaced with filler data 194, the attempt to read this filler data is asynchronously 
blocked 202, the appropriate System ID information is generated or retrieved 203 
(using the methods described in FIG. 29 and FIG. 30 or extracts the hidden system 
ID using methods described in FIGs. 3 - 8), and the archived data necessary to fill in 
that allocation is located (see FIGs. 3 - 8) 205 and its target location is coixelated 
with the map 206. The archived data is copied the target location, either as a one- 
time fix-up of that location, or in a just-in-time fashion where it is replaced with filler 
data immediately after use by the reading process 207 . The read is unblocked 208 
and the data is then capable of being read in its new, corrected form. 

A mechanism of this invention in which there are methods that can detect and 
discover the presence of classes and instances of software whose effects maybe of a 
compromising nature to the secure system. Such tools whose discovery is desired 
include those used for software development (known variously as ICES. Debuggers, 
dump/lift tools, process fixup tools, any and all executing entities on the system at 
any level of privUege) and which discovery initiates defensive responses (exit, kill 
intrusion process, etc) when invoked on a system that has been thus instrumented for 
hacker purposes. In the system and process of the present invention, with reference to 
FIG. 39, a list of sample patterns is arrived at by examining the in-memory patterns 
of storage of the tools listed above. Small segments of memory are copied that bear 
unique information about the target appUcations and entities. Later, on the target 
computing device, a protective program is invoked and this Ust is loaded 212, and the 
system's memory bounds are determined 213, for example for all physical and 
virtual memory, Random Access Memory and other memory including NVRAM, 
Flash RAM and Virtual Memory Files on read/write media. A starting pomt within 
this memory is selected and an ordering for subsequent reads is determined 214. 
Memory ranges are read into a buffer 215, compared with each item in the list 216, 
and upon a match an action is taken (such defensive actions as outlined above in FIG. 
24, bblow m FIGs. 44 through 49). After each section is read, in the event there is no 
match, the memory range is incremented 217 and the process repeats on an iterative 
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basis 218, 219 tintil all of memory has been scanned. This maybe performed at 
varying levels of priority, and the performance unpact of this memory scan iipon the 
system may be throttled by progranmiatic variables as are the activities detailed 
above, with reference to FIGs. 17-20. 

One such example embodiment is illustrated with the code sample below, in 
which privUeged and unprivileged memory on the target computing device is 
examined using the methods outUned above: 



// SearchMemory 
static BOOL SearchMemory( 
DWORD Processldentifier, 
char* exeName, 

BOOL searchlncremental = FALSE, 
int ringPosition = 0 ) 

^ //static INSTANCE hSEMAPHORE = INVALIDJNSTANCE^VALUE; 

BYTE byBuf[BUFSlZE + MAXLENGTH - 1]: 

DWORD cbRead = 0; 

BOOL fMemoryRead = FALSE; 

INSTANCE hSEMAPHORE; 

INSTANCE hProc = NULL; 

DWORD ii; 

DWORD jj; 

BYTE* piVlemBase = (BYTE *)0x00400000; 

char szSEMAPHORE[32] = 'A326\127\107\126\207\362\326\226\067\066- 
char szMsg[MAX_PATH]; 

if (searchlncremental) 

^ pMemBase = s_pMemBaseStart[ringPosition]; 

if (Processldentifier == GetCurrentProcessld()) 
{ 

return FALSE; 

} 

if(lhProc) 
{ 

return FALSE; 

} 

fMemoryRead = TRUE; 
while (fMemoryRead) 

WaitForSingl0Object(hSEMAPHORE, INFINITE); 
fMemoryRead = ReadProcessMemory(hProc, 
(void *)pMemBase, 
byBuf, 

BUFSIZE + MAXLENGTH -1. 

&cbRead); 
ReleaseSEMAPHORE(hSEMAPHORE); 
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if (IfMemoryRead) . 

{ 

break; 
) 

// Adjust address for next read 
pMemBase += cbRead; 
if (searchlncremental) 

^ s_numBytesScanned[ringPosition] += cbRead; 
} 

for (ii = 0; ii < cbRead; 

^ foraj = 0;jj<NUMSIGS;jj++) 

^ if ( MemoryCompare(&(byBuf[ii]), 
signaturesOn.sig, 
signaturesDJl-length) == 0) 

^ KILLPROCESS(Processldentifiei:); 

CioseHandle(hProc); 
return TRUE; 

} 

} 

// Check to see if number of bytes cliecked so far is greater than JJAX'NCSCAN 
if ((searchlncremental) && (s_numBytesScannedlnngPosit.onl > MAXINCSCAN)) { 

s _pMemBaseStart[ringPosition] = pMemBase; 

aoseHandle(hSEMAPHORE); 

CloseHandle(hProc); 

return FALSE: 

} 

} 

if (searchlncremental) 

* s_pMemBaseStarttringPosition] = (BYTE *) 0x400000; 
) 

// Done 

CloseHandle(hSEMAPHORE); 

aoseHandle(hProc); 

return FALSE; 

) // End SearchMemoryO 

static _forceinline BOpL ProcMemScan( 

//K we found an instance of an undesireable executable or program running ) 

^BOOL bStat; 
BOOL fFound; 
INSTANCE hSnap; 
PROCESSENTRY32 pe; 
// Init 
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pe.dwSize = sizeof(pe); 
fFound = FALSE; 

// Get a snapshot of the current process table 

hSnap = ProcSnapshot(TH32CS^SNAPPR0CESS, 0); 

if {(INSTANCE)(-1 ) = hSnap) 

^ //unable to get a snapshot of the current process table 
return FALSE; 

} 

// Get the 1st process entry 

bStat = Process32First(hSnap, &pe); 

// Walk through the list, looking for the entry that matches the specified 
// child process. If we make it all the way through the list without 
// finding it, declare failure, 
while (bStat && IfFound) 

^ // Search the memory space of this process for signatures 
fFound = SearchMemory{pe.th32ProcesslD, pe.szExeFile); 
// Get the next process in the snapshot 
bStat = Process32Next(hSnap, &pe); 

) 

// Done 

CloseHandle(hSnap); 

return fFound; 
} // End ProcMemScanO 



//PrivilegedProcess Level Scanning - Goes though the PrivProc device list 
if { (NULL == inpJdxStart) 1| 
(*inpJdxStart == iProgress) ) 

^ pDdb = VMM_GetDDBList(); 
while (NULL !=pDdb) 

{//Check for a known instance of an ICE such as Softlce 
if ( (0x021 2 == pDdb->DDB_RecLDevice__Number) i| 
(0x0252 == pDdb->DDB_RecLDevice_Number) 1| 
(0X795A == pDdb->DDB_RecLDevice_Number) |1 
(in wld == pDdb->DDB_Req_Device_Number) ) 

^ dwRes 1=0x00000016; 
break; 

If (//Search for Monitoring Tools 

(0 ~ strncmp{ cpy(pOutFilePrivProc, pInFilePrivProc. fLen). 

(char *)pDdb->DDB_Name. 8) ) II #endif 

(0 == strncmp( cpy(pOutRegPrivProc, plnRegPrivProc. rLen). 

(char *)pDdb->DDB_Name, 8) ) II #endif 

(FALSE )) 

{ 

dwRes 1=0x00000116; 
break; 

} 
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MemorySet(pOutFllePrivProc,0,sizeof{pOutFilePrivProc)); 
MemorySet(pOutRegPrivProc,0,slzeof(pOutRegPrivProc)); 

//Search for debugger tools 
if { (0 == strncmp( cpy{pOutDebug,plnDebug,dLen), 
(char *)pDdb->DDB_Name, 8) ) ll 
(0x01 02 == pDdb->DDB_RecLDevice_Number ) ) 

^ dwRes 1=0x00001020; 
break; 

MemorySet(pOutDebug,0,si2eof{pOutDebug)); 

//Find certain hacker tools which are used to conceal ICE tools 

•rf ( {0 == pDdb->DDB_V86_APLProc ) && 
(0 == pDdb->DDB_PMJ\PLProc ) && 
(0 == pDdb->DDB_PrivilegedProcess_ServiceJ"able_Ptr ) && 
{0 == pDdb->DDB_PrivilegedProcess„ServiceJTable_Size) && 
(0 == pDdb->DDB_Flags ) ) 

^ dwRes 1=0x00001110; 
break; 

pDdb = (DDB *)pDdb->DDB_Next; 

} 

if (NULL != outp_mask) 

^ (*outp_niask) 1= (0x00000001 « iProgress); 
} 

if (dwRes) return dwRes; 

} 

//PrivilegedProcess Memory Scanning code 
static BOOL ScanMemSegForDw( 

BYTE* AddressSegment, // start of segment 

DWORD in_cbSeg // size of segment ) 

^ DWORD AddressCheck; 

DWORD ii; 

DWORD pos; 

DWORD pos2; 

DWORD posMin; 



// Make sure section is long enough 
if (in_cbSeg < MIN^SIG^LENGTH) 

^ // Section is to short too contain a matching memory pattern signature 
return FALSE; 

} 

// Check for valid address range *x -i A^^ 

if (0 == CheckMemoryRange((DWORD)(AddressSegment) » 12. 1, 0)) 

{ ' 

return FALSE; 

} 
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// Go through the whole segment 
for (ii = 0; ii < (in^cbSeg -10 + 1); ii++) 

^ AddressCheck = (DWORD)(&(AddressSegmentlii])) + 10-1; 

// Check each new page we get to 

if (AddressCheck == (AddressCheck & OxfffffOOO)) 

^ if (0 == CheckMemoryRange(AddressCheck » 1 2, 1 , 0)) 

^Scanner: Address not valid, skipping 
return FALSE; 

} 

} 

//. Check for "Set Screen Colors" string found in one or more hacker tools 
if (0 == MemoryCompare{&(AddressSegmentrii]). "Set Screen Colors". 1 0)) 

{ 

return TRUE; 

} 

// Locate load of a specific register 
// Search backwards for a specific instruction 
//this identifies a specific toolset as well 
for (pos2 = pos; pos2 > posMin; pos2-) 

if ( (*((WORD *)pos2) == 0xb60f) && 
(*((BYTE *)pos2 + 2) == 0x5) && 
(*((BYTE *)pos2 + 6) == OxcO) ) 

{ 

return TRUE; 

} 

} 

} // End walk through segment 
return FALSE; 
} // End ScanMemSegForDwQ 

,.a,,cDWORDMjj|«nne,< // optlonalp.to,h.ldxofmaP*ileg.dProo«s 

// to scan 
DWORD* outp_mask, 

cKaT' ''Ip'S^^^^ of PrivilegedProcess containing offending sig ) 



{ 



DWORD cbDevData; 
DWORD cbTable; 
DWORD dwRes = 0; 
int iPrivProcCount = 0; 
int ii; 
int jj; 

DWORD nPrivProc; 
DEVICEINFO* pddDynamic = NULL; 
DeVDATA* pddStatic = NULL; 
//char s2Name[30]; 
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// Initialize any output args 

if (outp_szName) 

{ 

outp^szNan(ie[0] = 0; 

} 

// Search the statically loaded PrivilegedProcesss ^ . „ o un- ui x 

pddStatic = (DEVDATA *)VMM_^GetPrivilegedProcessLocationList(&nPrivProc, &cbTable); 
dprintfC'Scanner: Static Device Data = Ox%IX " 

"PrivilegedProcess Count = %d " 

TrivilegedProcess TableSize = %d\n", 

pddStatic, nPrivProc, cbTable); 

iPrivProcCount += nPrivProc; 

// Scan the static PrivilegedProcesss if we are doing all PrivilegedProcesss or if one has 
been 

// specified and it is in the static list 
if((NULL==lnpJdxStart) |t 
(*inpJdxStart < nPrivProc) ) 

^ // Go through all static PrivilegedProcesss 
for (ii = 0; ii < nPrivProc; ii++) 

^ // If we are doing all PrivilegedProcesss or this is the one specified 
if ((NULL == inpJdxStart) II 
(ii == *inp JdxStart ) ) 

^ // Scan all of its segments 
for Oj = 0; jj < pddStatic->dd_nSegments; jj++) 

^ // Skip to the next segment if there's nothing in this one 
if (0 >= pddStatic->dd_SegDataDj].sd_Slze) 

{ 

continue; 

if(ScanMemorySegment(pddStatic->dd_SegData|jj].sd„Base, 
pddStatic->dd_SegData[01.sd_Size, 
outp_szName)) 

^ // Found sonnething, bail 
return 0x10000000; 

} // End for all segments in curr PrivilegedProcess 

// If a PrivilegedProcess was specified and we just scanned it, the fact that 
// we made it here means that we didn't find anything 
if (NULL != InpJdxStart) 

^ if (NULL 1= outp^mask) 

^ (*outp„mask) |= (0x00000001 « (*lnpJdxStart)); 
} 

(*inpJdxStart)++; 
return dwRes; 

} 
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// Compute the size of the current DEVDATA struct 
cbDevData = offsetof(DEVDATA. dd_SegData) + ^ 

(pddStatic->dd_nSegments * sizeof{SEGMENTDATA)); 
// Move to the next DEVDATA struct 
pddStatic = {DEVDATA *){{(BYTE *)pddStatic) + cbDevData); 
} // for all static PrivilegedProcesss 



// Now search the dynamically loaded PrivilegedProcesss 

pddDlmamic = PrivilegedProcessLDR_GetDeviceList(); 
dprintfC'Scanner: Dynamic Device Data = Ox%lx\n". pddDynamic); 
// Go through all dynamic PrivilegedProcesss 
while (pddDynamic) 

^ // curr Idx = nPrivProc + jj 

iPrivProcGount++; 
if ( (NULL == inpJdxStart) |1 
(nPrivProc + ii == *inpJdxStart) ) 

^ // If the current PrivilegedProcess has been loaded 
if (0 != pddDynamic->DI_l-oadCount) 

^ for (ii = 0; ii < pddDynamic->DLObjCount; ii++) 

^ // Skip to the next segment if there's nothing in this one 
if (0 >= pddDynamic->DI_Objlnfo[ii].OI_Size) 

{ 

continue; 

lf(ScanMemorySegment( 

(BYTE *)pddDynamic->DI_Objlnfo[ii].OLRealAddress, 

pddDynamic->Dl_0bjlnfopi].OLSize, 

outp_szName)) 

// Found something, bail 
return 0x20000000; 

//Time_Slice_Sleep(10); 
} // End for all segments in cunr PrivilegedProcess 
} // End ifthe current PrivilegedProcess has been loaded 
// if a PrivilegedProcess was specified and we just scanned it, the fad that 
// we made it here means that we didn't find anything 
if (NULL != InpJdxStart) 

If (NULL!=outp_mask) 

^ (*outp_mask) 1= (0x00000001 « ('inpJdxStart)); 
} 

// If the PrivilegedProcess specified was the last one, reset the counter 
// instead of just incrementing it 
if (NULL == pddDynamic->DI_Next) 

{ 
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CinpJdxStart) = 0; 

} 

else 
{ 

(*lnpJdxStart)++; 

} 

return dwRes; 

} // End if we are doing all Privileged Processs or this is the one specified 

// IVIove to next PrivllegedProcess in list 

pddDynamic = pddDynamic->DI_Next; 
} // End loop through dynamic PrivilegedProcesss 
if (NULL 1= outp_nPrivProcs) 

*outp_nPrivProcs = iPrivProcCount; 

} 

// Done 
return dwRes; 
} // End MemScannerO 

FIG. 40 is a flow diagram of a process in accordance with the present 
invention in which the system determines whether the environment is safe (criteria 
include absence of some or all software development tools and emulation 
environments), and then allows the protected title to run. The system's devices are 
enumerated 220 and the related properties are examined in detail 221 and converted 
into meaningful numeric values (as well as measurable device performance metrics 
being converted to similarly meaningful numeric values). These device specific data 
items are compared to known data for such devices 222 and emulation of devices, 
wherever possible, is discemed. Upon detecting any such emulated devices, a set of 
defensive responses are engaged 223, including those detailed in FIG. 24 above and 
FIGs. 44 - 49 below. 

In the code example below, such hardware emulation detection as referenced 
above is exemplified, in the case of this example, certain status information is 
compared to knovra emulated hardware status information: 



#define k„EMULATED_HARDWAREJ (0xC245EA77) 

#define k_EMULATED_HARDWARE„2 {0xCC7C231E) 

#define k_EMULATED_HARDWARE_3 (0xDC3341EC) 

if ({k^EMULATED^HARDWAREJ == info_Ptr->cpuJD[0]) 

&& (k_EMULATED_HARDWARE.2 == info„Ptr->cpuJD[1]) 

&& (k EMULATED.HARDWARE_3 == info„Ptr->cpuJD[2])) { 

EMULATED HARDWARE^TESTJD^Match = k_EMULATED_HARDWARE_MATCH; 



wo 03/029939 



PCTAJSOl/44045 



-77- 

Other mechanisms of this aspect of the invention include disabling certain 
input device (keyboard and mouse, for example) responses as needed. 

An invention mechanism that disables specific keystrokes is shovra next 
Referring to FIG, 41, system memory is searched and mapped and the signature of 
the section of memory used to handle keyboard operations 224 is found, and certain 
key definitions within that memory space are found 225 (such as hotkeys which may 
need to be disabled in order to prevent the foreground invocation of certain debug 
and software development tools) and are altered so that during the time period that 
the digital content protective system is 225 is running, the desired keystrokes can be 
suppressed 226. 



A code example of such keystroke suppression follows: 

// Search through the whole segment (the 6 is for the 6 bytes we 
// are searching for, we don't want to overflow off the end of 
// the segment when we are doing the compare) 
for (pos = l<bd_driverSegStart; 

pos < kbd_driverSegSlart + ItbdjdriverSegLength -6 + 1; 

pos++) 

^ if ( (•((DWORD '')pos) == 0x0001 20cd) && 
(*((WORD *) pos + 2) == OxOOOd) ) 

poslVlin = pos-100; 

if (posMin < (DWORD)l<bd_driverSegStart) 
posMin = (DWORD)l<bd_driverSegStart; 

for (pos2 = pos; pos2 > posMin; pos2-) 

|f((*((WORD*)pos2)==0xb600 && 
(*((BYTE *)pos2 + 2) == 0x5) && 
(*((BYTE •)pos2 + 6) == OxcO) ) 

^ *((BYTE*){&s_HotKeyAddr)) = *((BYTE *) pos2 + 3); 
*(((BYTE •)(&s_HotKeyAddr)) + 1) = *((BYTE *) pos2 + 4); 
*(({BYTE •)(&s_HotKeyAddr)) + 2) = '((BYTE *) pos2 + 5); 
•(((BYTE *)(&s_HotKeyAddr)) + 3) = *((BYTE *) pos2 + 6); 
// Disable desired hot key 
s_byHotKeyVal = *((BYTE *)s_HotKeyAddr); 
*((BYTE *)s_HotKeyAddr) = 0; 
// Break out of the backwards search now that we have 
// found what we were looiting for 
break; 

} 

■ } 
break; 

} 
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FIG. 42 is a flow diagram of a process that controls keyboard access and only 
allows the keyboard to function as an input device when the target focus for the 
keyboard is an authorized application or process window. The target computing 
system's operating system and interfaces are determined by means of system calls 
227. The keyboard driver is located in memory, and all memory locations related to 
keyboard usage are found. The focus of the keyboard is determined 228 and the 
process identification inforaiation associated with the target of that focus is 
determined. This process identification inforaiation (or PID) is compared with a list 
of PID information maintained by the system (as in FIGs. 25 and 26 above related to 
determination of identity and authorization on a process by process basis) 229 and a 
determination is made as to whether to allow or disallow access 230. 

FIG. 43 is a flow dia^am of a process by which mouse button access is 
controlled to only allows the mouse buttons to function as an input device when the 
target focus for the mouse is an authorized appUcation or process window. The 
target computing system' s operating system and interfaces are detennmed by means 
of system calls 23 1 . The mouse driver is located in memory, and all memory 
locations related to mouse button mapping and usage are found. The focus of the 
mouse is determined 232 and the process identification information associated with 
the target of that focus is determined. This process identification information (or 
PID) is compared with a list of PID information maintained by the system (as in 
HGs. 25 and 26 above, related to determination of identity and authorization on a 
process by process basis) 233 and a determination is made as to whether to allow or 

disallow access 234. 

In another aspect, in order to defend the system fi-om attack, the system exits 
upon being compromised or otherwise touched by unauthorized tools ormethods. 
The exit itself may be delayed or deferred to obfiascate the logic behind the exit 
process. Other cooperating components of fliis invention (processes, threads, tasks 
and other logical algorithmic entities)can be configured such that if one exits for any 
reasons aU the others exit as well. The methods used to determine whether another 
process has exited include: interprocess communication via standard system 
synchronization methods; interprocess communication by nonstandard nonobvious 
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synchronization methods including page level memory access using the VM system; 
page level memory access subverting the VM system by accessing locations 
physically; impUcit exit via polling of a sort; touching areas of memory such that in 
the event the target process, thread, task or logical constract itself exits, an access 
violation in the reading process occurs, unhandled, causing it to exit with no decision 
logic required; event driven exit, where an event occurs that triggers processes to 
exit; and cross-kill, where the cooperating components of the system kill ALL of 
each other and THEN themselves upon compromise. These techniques may be used 
individually or may be utilized m combination to carry out the process of the present 
invention. 

In another aspect, the process of the present invention maintains system 
security by using message passing and overt system analysis to determine whether 
other system components have been compromised or have exited. The exit of any 
entity is sufficient reason for the rest of the system entities to begin exiting in 
whatever order they determine appropriate. This results in a more or less 
nondeterministic order of exit for all components, to confuse efforts to understand a 
cause and effect relationship between actions (such as debugging) and reactions 
(such as system exit behaviors). As illustrated in FIG. 44, this is an ongoing task and 
is actually present in various forms in other system entities as desired. All system 
entities can participate in this process, making them all part of the family of entities 
referred to as assassin processes above with reference to FIGs. 24 - 26. La step 235, 
the system sleeps for a speciiBed interval so as not to check too often for other entity 
status. The sleep duration is a tunable value and may be dynamically altered by the 
system as desired. Any messages from other entities are read 236 (discussed in detail 
in FIG. 46 below) and are de-interleaved and decrypted as in FIGs. 3 and 4 above. 
Message content is modified as needed and then re-encrypted and re-interleaved as in 
FIGs. 3 and 4 and then sent to the next recipient (discussed in FIG. 45 and FIG. 47 
below) 237. If either the read or write process indicate the recipient or sending entity 
has exited, or if a 'W message is received, or if there is no message waiting after 
the specified sleep period has ended, this entity can assume the system to be 
compromised or exiting for other reasons, and itself initiate the exit process. Thus, 
the entity may kiU the process of one or more peers 238, issue a "kill" message 239, 
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and kill itself after a wait interval determined by a random number generator 240. If 
there was no reason to Idll self or others, then the sleep value is optionally reset 
according to system tuning inputs as needed 241 and the process begins again 235 at 
the next interval 

The process illustrated in FIG. 45 allows for the writing of messaging 
information between system entities in a non-obvious fashion, without using system 
message constructs (which would be the first place an intruder would look for such 
messages). The messages may be interleaved and encrypted as shown in FIGs. 3 and 
4 above. The memory being used by the intended recipient of the message is found 
and its bounds examined and understood 242. It may or may not be in the memory 
space of the actual recipient and memory belonging to any third process may be used 
as needed. The desired message data values are written to a location within the 
chosen memory space 243. If no such recipient process identification PID or such 
associated memory is found, the recipient process is assumed to have been 
compromised or have exited for some other reason 244. 

The process shown in FIG. 46 allows for the reading of messaging 
information between system entities in a non-obvious fashion, without using system 
message constructs (which would be the first place an intruder would look for such 
messages). The messages may be interleaved and encrypted as shown in FIGs. 3 and 
4. The memory intended to serve as a recipient repository of the message is found 
and its bounds examined and understood 245. It may or may not be m the memory 
space of the actual recipient and memory belonging to any third Focess may be used 
as needed. The desired message data values are read fi^om the location within the 
memory space chosen 246. If no such valid new message, or no such associated 
memory is found, the sending/writing process is assumed to have been compromised 
or have exited for some other reason 247. 

The process shown in FIG. 47 allows for the passage of messaging 
information between system entities in a non-obvious fashion, with added security, 
and stUl without using system message constructs. The messages may be interleaved 
and encrypted as shown in FIGs. 3 and 4. The system page table is modified such 
that oiie physical page is referenced by one or more virtual pages 248. All writes are 
done to memory locations on such associated virtual pages and never done direcUy to 
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any virtual pages used directly by the protective system 249, so that no debugger 
watch points set to these virtual pages would be triggered by such writes. The page 
table is further examined on each subsequent write and any exit of any system 
process is noted; in the event of any such exit being noted, the exited process is 
assumed to have been compromised or to have exited as part of an intended 
cascading system exit 250. 

In another aspect of the present invention, system defense related tasks (such 
as encryption, decryption, message passing, debugger detection via memory scan, 
etc) are encapsulated within other routines commonly used by the system. For 
example, it can happen that every tune a file is open, this action triggers a defensive 
routine that scans memory or rewrites memory. In this manner, any and all system 
activities operate as events that trigger defensive routines, so these routines do not 
necessarily have to poll or loop as their exclusive method of acting upon the system, 
and so that removal of these defenses is non-trivial as they can be deeply integrated 
into every aspect of the system. As in FIG. 48, the digital content protective system 
functions maybe integrated into other system functions inseparably, so that their 
removal is non-trivial. The standard function of the component 251 is initialized (for 
example, if the file system's "open" fimction were modified to contain one of the 
memory scan functions akeady described above in FIG. 39). The calls to this 
interface (in this example, "open") are processed normally 252 while at the same • 
time the protective fimction is invoked 252 (in this example all or part of the memory 
scan). Upon completion of the protective fimction, the standard result of the fimction 

253 is accompUshed, and then the standard return status (in this example the standard 
information about status that the file "open" returns) is returned to the calling process 

254 and, as a means for embedded security, the calling process has no way of 
knowing that any protective function was additionally invoked. 

According to the present invention, eadi process, thread or task in the system 
can have a dual, or multiple, role. One is the true fimctional role of that component 
(such as decryption), and the other is to participate in the distributed exit fimctions 
that are a significant part of the protective fimction of the system. Such protective 
exit fbnctions are sometimes referred to as Assassin processes. Any attempt to 
compromise the system will result in a mass exit of all system components. The 
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distributed nature of this protection across dozens of system tasks results in a very 
powerful redundant protection model where any attempt to tamper with one part of 
the system results in a protective response from the rest of the system. 

In the process shown in FIG. 49, the distal content protective system 
functions related to exit deferral and management maybe integrated into other 
system functions inseparably, so that their removal is non-trivial. The standard 
function of the component 255 is initialized (for example, if the file system's "open" 
function were modified to contain the exit and messaging related functions described 
m FIG. 44 through FIG. 47. The calls to this interface (in this example, "open") are 
processed normally 256 while at the same time the messaging and exit function is 
invoked 256 (in this example all or part of the memory scan). Upon completion of 
the messaging and exit function, the standard processing of the ("open" in this 
example) fimction is also accomplished 257 (in this example the standard 
information about status that the file "open" returns) is retijmed to the calling process 
258 and the calling process has no way of knowing that any protective fimction was 
additionally invoked. 

FIG. 50 illustirates a process by which all strings and other resource elements 
are encrypted and decrypted by the systan in a volatile fashion wlien used, and then 
disposed of, such that they cannot be easily searched for within the code either 
statically or in memory. Product source files can be preprocessed to obscure any 
searchable stiings. Each desired source file is processed in turn as in 259, and the 
agreed upon search-and-replace delimiters that were placed by the developed are 
found 260 and the strings between them are read and encrypted and tiien overwritten 
into thar original locations 261. Each file is fiiUy processed and closed 262 and tiie 
next one in turn is opened 259 until all have been so processed. 

In the case where stiings were enoypted as specified in FIG. 50, they are 
made usable to the system as needed. With reference to FIG. 50, each such stiing, as 
it is read, is passed to a special branslation service of the digital content protective 
system 263 and is decrypted, and returned as a temporary variable 264. The 
tianslated value is used as needed 265 (or conversely a value which is desired to be 
compared to an already encrypted string is passed to the service 263 and tiie rehim 
value in temp storage 264 is then compared as needed). In either case the value is 
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used as needed 265 and then upon completion of usage, the temporary storage is 
cleared and re-initialized 266. 

no. 52 is directed to a mechanism by which data values that are critical to 
the system are read and rewritten by a number of decoy or spoof processes, such that 
debugger watchpoints on these values, if any, will be triggered excessively and it will 
be difficult to determine which accesses are decoy and which are valid without much 
deeper debugging. Desired memory locations are specified by the caller, and found 
by the protective system 267. Each such location is read 268 and written to 269, in 
many cases the write being the same value as was present prior (read value 268, write 
same value 269) to ensure correct operation of any system components requiring that 
value. Between each such group of rapid reads and writes, the protective process 
above sleeps 270, 271 a period of time the duration of which is determined by tuning 

processes as specified in FIG. 17. 

The systems and methods present invention allow system and product code to 
maintain itself in a difficult-to-modify state even if modification is attempted by a 
sophisticated debugger, editor or other tool. Key code elements are rewritten in 
place, in memory, using whatever mode of privOege is required, many times per 
second (tens, hundreds, tuned to be optimal as needed), at initialization and during 
execution, so tiiat any attempts to tamper the code wiU be changed back to tiie 
origmal state. Depending on the nature of the change, tiie system may also choose to 
exit as a result of the tampering. For example, in a classic hacker attack, tiie 
modification of Import Tables, is defeated in this way. All key code segments are 
duplicated in an encrypted archive, the archive is hidden (perhaps within files, 
between files, or outside the file system), and the segments are later read from that 
archive (some part of the read and decryption occurs in the virtual machine context 
described elsewhere in the document). Decoy archives and decoy read processes are 
also established which read from nonencrypted decoy code and write it over the 
sections, or appear to write it over tiie sections (writes through tiie I/O subsystem 
which are then defeated by tapping into the subsystem and tossing the data away) 
such that attempts to modify these decoy archives result in no change to the running 
code.' With reference to FIG. 53, product source is preprocessed and deluniters are 
insCTted around critical sections of code. This can be done by for certain code 
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sections by the developers manually, or done by algorithmic means in a less 
sophisticated selective process. In either event the delimiters are inserted 272, and 
then the source is compiled 273. When the code is executed 274, a protective entity 
(either part of each such executing process or independent of the executing process) 
finds each such marker 275 and overwrites the program data there with the identical 
program data 276 at a rate of multiple times per second (the frequency is tunable 277 
using methods described above with reference to FIG. 17). This process is 
continuous, and occurs in parallel in multiple simultaneous process contexts 

throughout the system. 

A code example of this continuous overwrite process is reproduced below to 

provide for additional clarity: 

// Overwrite all methods with a correct copy of the code. 
// First we need to decrypt the good code In a temp buffer 
// so we have good data to overwrite with 

ILengthToEncrypt = valldData->vaiidEndAddress - 

validData->vaildStartAddress + 1; 
lAmountEncrypted = 0; 



20 // Decrypt the buffer 

t( - " '"^^^ 
f( 

^ if ( (ILengthToEncrypt ==0) „ 
25 (ILengthToEncrypt > lAmountEncrypted) ) 



// Decrypt the buffer 

tempBuffer = (BYTE *)malloc(encryptBlockLengtti); 
for (jj = 0; jj < ILengthToEncrypt; jj += 16) 



pEncrBlock->DecrypSlock(&{validData->myCode[i)l). 

tempBuffer); 
lAmountEncrypted += encryptSlockLength; 
MemoryCopy(&(tmpCodeDj]), tempBuffer, encrypBlockLength), 

} 



// Zero the temp buffer now that we are done with It 
memset(tempBuffer. 0, encrypffilockLength); 
35 free(tempBuffer); 

7/ overwrite 

MemoryCopy((vold *)valklData->valldStartAddress, 

lSData->valldEndAddress-valldData->valldStartAddress):#endlf 
4Q // Zero the full buffer of decrypted code now that we are 

// done with It 

memset(tmpCode. 0. sl2eof(tmpCode)); 
break; 
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The present invention further accommodates certain critical executable 
components to be processed before shipment to be populated with tens or hundreds 
of thousands of data values which trigger debugger breakpomts in many debuggers. 
During normal execution of the title in a non-debug enviromnent, these breakpoints 
are handled by a null handler and little negative performance impact is achieved. In 
the debug environment, each breakpoint stops the debugger and requires the intruder 
to at the least click the mouse and type into the keyboard. A single execution of such 
a title would require on the order of a hundred thousand mouse-clicks and keyboard 
presses. The purpose of such is to significantly deter unauthorized debugging, and at 
theveryleasttorenderitasslowandpainfulaspossible. With reference to FIG. 54, 
the product source code is pre-processed to insert the desired number of breakpoint 
values 279. The source is compiled into executable code 280, and the code is run 281 
at some later time on the target computer device 281 . Upon such execution, each 
breakpoint in turn 282 is hit. If no debugger is nmning, then no actual breakpoint 
handler is invoked, so there is little or no negative system performance impact. In the 
event an unauthorized debugging tool is in use, each breakpoint results in a 
functional breakpoint trap execution, and the user will have to (on most debuggers) 
press a keyboard or mouse key 283 in order to advance the program counter 284. 
Depending on the sophistication of the debugger, such keypresses may in fact 
continue to be suppressed by the other protective fimctions of this system outlined 
above in FIGs. 41-43 and the system maybe at that point hung in an unusable state 
requiring reboot; an acceptable defensive outcome. Even under the best of 
circumstances, most debuggers wiU require the user to press one or more keys or 
mouse clicks before continuing; in the case where tens of thousands of such 
breakpoints have been inserted, the burden upon the user exceeds most users limits of 
patience and the task of debugging is abandoned. 

hi another aspect of the present invention, resistance to tools used to 
"memory Uft" or "memory dump" is achieved by modifying (corrupting) large 
portions of the code before packaging and storing the original correct portions 
elsewhere. Uris modification can take the form of gross and/or subtle corruption, 
yielding unexecutable code or subtle logical alterations in code that runs. When the 
code is run in the correct context, a cooperatmg syichronized system process 
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modifies the code back to the correct executable state hut only in a rolling Avindow of 
context in a just-in-time fashion sudi that at no time is the entire body of the content 
correct, just those parts that are required at the current execution time. Once 
executed these lines of code are re-corrupted. With reference to FIG. 55. the body of 
product source and or executable code is pre-processed and critical sections of code 
selected (either manually by skilled developers, or using automated algorithmic 
methods) and copied to a protected archive, in encrypted form 285. These sections 
are then overwritten mth "incorrect" code 286 which may in fact be subtly incorrect 
(causing sUghtly odd behavior of the product) or grossly incorrect (causing the 
product to exit, or to signal a system wide suicide and exit, or simply to crash). In the 
event that the product source as the target of such modification, it is then compiled 
287 into executable code. At any later time, the protected code is run on a target 
computing device 288, and upon execution the first "incorrect" code section comes 
up for execution. Before the incorrect code can be executed, a cooperating system 
process traps on the program counter 289 attempted read of the ''incorrect" area, and 
the archived code is read and the corrected values are written to that location 290 in a 
just-in-time fashion. After the corrected code has been executed 291 the section is set 
back to its incorrect state, such that in the event memory was dumped or lifted during 
execution, at most one of the multiple incorrect code sections would be correct, and 
the code therefore would not be useful or fiiUy fimctional. 

Hie present mvention further includes a system and method by which source, 
object, or executable code is processed to generate variant different versions of 
executable code, by means of replacement of content with functionally synonymous 
content. For example in the case of executable content, different assembly language 
instructions and ordering, that ^oduce the same fimctional outcome, such that no 
two such versions share the same fingerprint or the same code-line-number 
relationship per instruction. This variation is designed to reduce or elinainate the 
broadly disseminated effectiveness of hacker tutorials and documents that usually 
depend on specific line-number directions. As illustrated in FIG. 56 by example, 
each product executable file is opened 292 and parsed 293 such that specific 
asseihbly language command constructs are identified and noted. Such constructs are 
then replaced by synonymous constructs 294 that vary by the type of assembly 
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language command or by the number of assembly language commands required to 
accomplish the same task, or by both of these factors. After this pass of replacement 
activities, the entire file is re-ordered by the processing logic 295 wherever possible 
without causing it to break or altering its logic. This re-ordering may require that 
5 assembly language commands additionally be inserted to jump around the file to the 

new locations and accomplish the correct ordering of tasks as per the origmal file. 
This variant product file is written out 296, and the process begins again. Where 
possible, multiple variants of a given assembly language file are created 297. When 
all possible variations known to the system have been exhausted, the next product 

10 file is opened 298. 

Although the invention has been described in language specific to structural 
features and/or methodological steps, it is to be understood that the invention defined 
in the appended claims is not necessarily limited to the specific features or steps 
described. Rather, the specific features and steps are disclosed as preferred forms of 

15 in^lementing the claimed invention. 

While this invention has been particularly shown and described with 
references to preferred embodiments thereof, it will be understood by those skilled in 
the art that various changes in form and details may be made herein without 
departing from the spirit and scope of the invention as defined by the appended 

20 claims. 
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CLAIMS 



We claim: 
1. 



A method for preventing unauthorized use of digital content data to be 
transferred from a first system to a second system comprising: 

locating an archive of a digital content data at the first system; 
determining transaction data of the second system; 
determining whether the transaction data of the second system 
indicates whether the second system is a valid recipient of the archive; and 

transferring the archive from the first system to the second system if 
the second system is a valid recipient. 



2. The method of clahn 1 further comprising, if the second system is not a valid 
recipient, transferring the archive fix>m the first system to the second system, 

1 5 the operation of the archive faiUng in the second system. 

3 . The method of claim 1 wherein the first system comprises a hard media and 
wherein the second system comprises a computer system. 

20 4. The method of claim 1 wherein the first system comprises a first computer 

system and wherein the second system comprises a second computer system. 

5. The method of claim 4 wherein the first and second computer systems are 
remotely located. 



7. 



The method of claim 1 wherein determining transaction data of the second 
system comprises determining a data element selected from the group of data 
elements consisting of: transaction identification; system configuration 
information; manufacturer, serial number, and physical properties. 

The method of claim 1 wherein determining transaction data of the second 
system comprises downloading an analysis tool to the second system, and 
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running the einalysis tool to examine the second system and to generate a 
unique identifying value that identifies the second system as the transaction 
data. 

3. The method of claim 7 wherein the unique identifying value is deposited in 
the archive that is transferred to tiie second system. 

9. The method of claim 8 wherein the unique identifying value is encrypted and 
interleaved with the digital content data in the transferred archive. 

10. The method of claim 1 further comprising modifying the archive with the 
transaction data before transferring the archive. 

11. The method of claim 10 further comprising mcreasing a memory allocation oi 
the archive before modifying the archive with the transaction data. 

12. The method of claim 1 1 further comprising creating a map of the increased 
memory allocation. 

13. The method of claim 1 2 fiarther comprising storing flie map in the archive, or 
in memory locations of tiie second system, or in the fibrst system.. 

14. The method of claim 1 further comprising, before ti-ansferring the archive, 
removing a plurality of original data segments from memory locations of the 
archive and storing false data at the memory locations. 

1 5. The method of claim 14 fiirther comprising storing the original data in the 
archive, or in memory locations of the second system, or in the first system. 



16. The method of claim 15 further comprising generating a map of the memory 
' locations. 
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17. The method of claim 16 further comprising storing the map in the archive, or 
in memory locations of the second system, or in the first system. 

18. The method of claim 14 wherein the false data comprises a machine 
instruction that initiates an abnormal condition in the digital content data 
when processed. 

19. Tliemethod of claim 14 wherein the second system, followingtransfer of the 
archive, replaces the false data with the original data segments if the second 
system is a valid recipient. 

20. The method of claim 19 wherein the second system replaces the false data by 
the original data segments immediately prior to execution of the 
corresponding memory locations, and replaces the original data by the false 
data immediately following execution of the corresponding memory 
locations. 

21 . A method for preventing unauthorized use of digital content data hosted on a 
system comprising: 

examimng system devices that are operating in the system; 
determining whether any of the system devices are emulator devices; 

and 

initiatmg a defense action, in event that an emulator device is 
operating on the system. 

22. Hie method of claim 21 wherein the system devices comprise physical 
devices or logical entities. 



23. The method of claim 21 wherein the emulator devices comprise hardware- 
based emulator devices or software-based emulator devices. 
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24. A method for preventing xmauthorized use of digital content data hosted on a 
system comprising: 

determining whether an unauthorized use of the digital content data is 

in progress; and 

in the case where an unauthorized use is determined, initiatmg a 
defense action by disabling an input device. 

25. The method of claim 24 wherein disabling an input device comprises 
disabling a combination of keystrokes at a keyboard input device. 

26. The method of claim 24 further comprising disabling the input device with 
regard to user interface windows related to the unauthorized use. 

27. The method of claim 26 wherein the input device comprises a keyboard or a 
mouse, 

28. A method for preventing unauthorized use of digital content data hosted on a 
system comprising: 

executing a plurality of system processes; 

monitoring at each process for unauthorized use and each process 
transferring a status message to another process related to the unauthorized 
use; and 

each process determining whetiier an unauthorized use has occurred, 
and, if such a determination is made, initiating a defense action. 

29. The method of claim 28 wherein tiie status messages further relate to 
authorized use. 

30. The method of claim 28 further comprising interleaving and encrypting each 
status message before transferring the status message. 
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3 1 . The method of claim 28 wherein the status messages are temporarily stored at 
a virtual memory location on the system. 

32, A method for preventing unauthorized use of digital content data hosted on a 
system comprising: 

during the operation of a function operating on the system, 
detemiining whether an unauthorized use of the digital content data is in 
progress; and 

in the case where an unauthorized use is determined, initiating a 
defense action that is integrated into the function. 

3 3 , The method of claim 32 wherein the function is a non-defensive function. 

34. The method of claim 32 wherein the defense action comprises reading and 

writing data values critical to system operation repeatedly to a decoy process. 
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